Successfully reported this slideshow.

Next Generation Internet Over Satellite


Published on

Published in: Technology, Business
  • Be the first to comment

Next Generation Internet Over Satellite

  1. 1. Next Generation Internet (NGI) over Satellite<br />1<br />Presented By: Reza Ghanbari<br />Department of Engineering<br />
  2. 2. Contents<br />Introduction<br />New services and applications<br />Internet integrated services <br />Elastic and inelastic traffic<br />QoS provision and network performance<br />Traffic modeling and characterization<br />Traffic modeling techniques<br />Scope of traffic modeling<br />Statistical methods for traffic modeling<br />Renewal traffic models<br />Markov models<br />Fluid traffic models<br />Auto-regressive and moving average traffic models<br />Self-similar traffic models<br />2<br />
  3. 3. Contents<br />The nature of internet traffic<br />The world wide web (WWW)<br />Pareto distribution model for self-similar traffic<br />Fractional Brownian motion (FBM) process<br />Consideration of user behaviour in traffic modeling<br />Voice traffic modeling<br />On-off model for voice traffic<br />Video traffic modeling<br />Multi-layer modeling for internet WWW traffic<br />3<br />
  4. 4. Contents<br />Traffic engineering <br />Traffic engineering principles<br />Internet traffic engineering<br />Multi-protocol label switching (MPLS)<br />MPLS forwarding paradigm<br />MPLS basic operation<br />MPLS and Diffserv interworking<br />MPLS and ATM interworking<br />MPLS with traffic engineering (MPLS-TE)<br />4<br />
  5. 5. Contents<br />Internet protocol version 6 (IPv6)<br />Basics of internet protocol version 6 (IPv6)<br />IPv6 addressing<br />IPv6 networks over satellites<br />IPv6 transitions<br />IPv6 tunneling through satellite networks<br />The 6to4 translation via satellite networks <br />Issues with 6to4<br />Future development of satellite networking<br />5<br />
  6. 6. Introduction<br />New generations of mobile telephones is more sophisticated<br />By increasing capabilities of email, WWW access, multimedia messaging, streaming voice and video broadcasting.<br />Mobile phone <br />Is more like a computer than a telephone. <br />Uses internet protocol stacks (TCP/IP), <br />Uses transmission technologies (infrared, wireless, USB, etc.)<br />Uses various peripheral devices<br />Uses Ethernet and wireless LANs dominate LANs<br />6<br />
  7. 7. Introduction<br />Mobile networks<br />As GSM mobile networks are evolving towards 3G networks.<br />Are converging towards an all-IP solution. <br />Satellite network<br />It is evolving towards an all-IP solution.<br />It is following the trends in the terrestrial mobile and fixed networks. <br />Its terminals aim to be the same as terrestrial network terminals providing the same user interface and functionality. <br />As the current satellite networks integrate with terrestrial networks.<br />7<br />
  8. 8. Introduction<br />Traditional computer network<br />QoS, traffic engineering and security were not very concerned by network designers<br />New requirement of people<br />Portable computers and mobility<br />Internet security <br />Due to more business transactions, commercial and public<br />Issues of Internet<br />The original design did not take all these new requirements <br />The large scale of today’s Internet into consideration.<br />IPv4 may soon run out of IP addresses<br />IPv6 has started to address these issues<br />8<br />
  9. 9. Introduction<br />Consideration<br />Discussing new services and applications (starting from information processing).<br />Developing the satellite networks and related issues, including traffic modeling and characterization, MPLS, traffic engineering and IPv6.<br />9<br />
  10. 10. New services and applications<br />The services information has to be encoded.<br />Decoded at the receiver.<br />Include major components of high-quality digital voice, image and video.<br />10<br />
  11. 11. Internet integrated services<br />Offer universal connectivity<br />Uniform service interface<br />Higher layer protocols – in particular, to transport layer protocols – independent of the nature of the underlying physical network.<br />The function of transport layer protocols is to provide session control servicesto applications, without being tied to particular networking technologies.<br /> <br />11<br />
  12. 12. Internet integrated services<br />In the specific case of IP, the IETF has developed the notion of an integrated services Internet. <br />This envisages a set of enhancements to IP to allow it to support integratedor multimedia services.<br />Network protocols rely upon a flow specification to characterize the expected traffic patterns for streams of IP packets.<br />12<br />
  13. 13. Internet integrated services<br />A flow is a layer-three connection, since it identifies and characterizes a stream of packets, even though the protocol remains connectionless.<br />13<br />
  14. 14. Elastic and inelastic traffic<br />There are two main classifications:<br />Elastic traffic<br />This type of traffic is essentially based on TCP, i.e., it uses TCP as the Transport protocol.<br />Known as opportunistic traffic.<br />FTP is an example of a long-lived responsive flow while HTTP represents a Short-lived flow.<br />14<br />
  15. 15. Elastic and inelastic traffic<br />Inelastic traffic<br /> This type of traffic is essentially based on UDP, i.e., it uses UDP as the Transport protocol.<br />The trafficis incapable of varying its flow rate when faced with changes in delay and throughput across the network.<br />This stream traffic is also known as long-lived non-responsive flow.<br />At present the Internet carries computer data traffic almost exclusively.<br />Traditionally these have been applications such as file transfer (using the FTP, remote login sessions (telnet) and email (SMTP).<br /> <br />15<br />
  16. 16. QoS provision and network performance<br />Best-effort service is the default service that a network gives to a datagram between the source and destination in today’s Internet networks.<br />If a datagram changes to a best-effort datagram, all flow controls that apply normally to a best-effort datagram also apply to the datagram.<br />Guaranteed service means that a datagram will arrive within a limited time with limitedpacket loss ratio, if the flow’s traffic stays within its specified traffic parameters.<br />16<br />
  17. 17. QoS provision and network performance<br />This service is intended for applications requiring a firm guarantee of delay within a certain time limit for the traffic to reach its destination.<br />Some audio and video ‘playback’ applications are intolerant of any datagram arriving after their playback time.<br />Datagrams often arrive far earlier than the delivery deadline and have to be buffered at the receiving system until it is time for the application to process them.<br />17<br />
  18. 18. Traffic modeling and characterization<br />Future network infrastructures will have to handle a huge amount of IP traffic from different types of services, including a significant portion of real-time services.<br />The ability to support different classes of services with different QoS requirements.<br />Internet traffic is more variable with time and bandwidth, with respect to traditional traffic intelecommunication networks, and it is not easily predictable.<br />18<br />
  19. 19. Traffic modeling and characterization<br />That networks have to be flexible enough to react adequately to traffic changes.<br />19<br />
  20. 20. Traffic modeling techniques<br />Multi-services networks need to support a varied set of applications.<br />These applications and services require resources to perform their functions.<br />Traffic engineering is a network function that controls a network’s response to traffic demands and other stimuli (such as failures) and encompasses trafficand capacity/resource management.<br />20<br />
  21. 21. Traffic modeling techniques<br />To devise efficient resource and traffic management schemes requires an understanding of the source traffic characteristics and the development of appropriate traffic models.<br />Traffic modeling is identified as one of the key subcomponents of the traffic engineering process model.<br />21<br />
  22. 22. Scope of traffic modeling<br />Traffic characterization describes what traffic patterns the application/user generates.<br />The Goal is to develop an understanding of the nature of the traffic and to devise tractable models that capture the important properties of the data, which can eventually lead to accurate performance prediction.<br />Traffic modeling summarizes the expected behavior of an application or an aggregate of applications.<br />22<br />
  23. 23. Scope of traffic modeling<br />Among the primary uses of traffic characteristics are: <br />Long-range planning activities (network planning, design and capacity management).<br />Performance prediction, real-time traffic control/management and network control. Traffic models can be utilized in three different applications:<br />As a source for generating synthetic traffic to evaluate network protocols and designs. This complements the theoretical part of the analysis, which increases in complexity as networks become complicated.<br />23<br />
  24. 24. Scope of traffic modeling<br />As traffic descriptors for a range of traffic and network resource management functions. These include call admission control (CAC), usage parameter control (UPC) and traffic policing. These functions are the key to ensure meeting certain network QoS levels while achieving high multiplexing gains.<br />As source models for queuing analysis, they use queuing systems extensively as the primary method for evaluating network performances and as a tool in network design. A reasonably good match to real network traffic will make analytical results more useful in practical situations.<br />24<br />
  25. 25. Statistical methods for traffic modeling<br />The main aim of traffic modeling is to map accurately the statistical characteristics of actual traffic to a stochastic process from which synthetic traffic can be gemerated.<br />For a given traffic trace (TT), the model finds a stochastic process (SP) defined by a small number of parameters such that:<br />TT and SP give the same performance when fed into a single server queue (SSQ) for any buffer size and service rate.<br />TT and SP have the same mean and autocorrelation (goodness-of-fit).<br />Preferably, SP SSQ is amenable to analysis.There are many traffic models that have been developed over the years.<br />25<br />
  26. 26. Renewal traffic models<br />A renewal process is defined as a discrete-time stochastic process, X(t), where X(t) are independent identically distributed (iid), non-negative random variables with a general distribution function. <br />Independence here implies that observation at time t does not depend on the past or future observation, i.e., there is no correlation between the present observation and previous observations.<br />26<br />
  27. 27. Renewal traffic models<br />Analyzing renewal processes is mathematically simple. However, there is one major shortcoming with this model: <br />the absence of an autocorrelation function. Autocorrelation is a measure of the relationship between two time instances of a stochastic process.<br />It is an important parameter and is used to capture the temporal dependency and burst of the traffic.<br />27<br />
  28. 28. Markov models<br />The Poisson and Bernoulli processes display memory-less properties in the sense that the future does not depend on the past <br />i.e., the occurrences of new arrivals do not depend on the history of the process. <br />This in turn results in the non-existence of the autocorrelation function since there is no dependency among the random sequence of events.<br />Markov-based traffic models overcome this shortcoming by introducing dependency into the random sequence.<br />28<br />
  29. 29. Markov models<br />Markov process is defined as a stochastic process X(t) where for any t0 < ··· < tn < tn+1 and given the values of X(t0 ) X(tn), the distribution of X(tn+1) only depends on X(tn).<br />Another important implication of this Markov property is that the next state only depends on the current state and not on how long the process has already been in that (current)state.<br />29<br />
  30. 30. Fluid traffic models<br />Fluid traffic models view traffic as a stream of fluid characterized by a flow rate (e.g., bits per second), that traffic volume is better than traffic count in the model.<br />Fluid models are based on the assumption that the number of individual traffic units (packets or cells) generated during the active period is so large that it appears like a continuous flow of fluid.<br />30<br />
  31. 31. Fluid traffic models<br />An important benefit of the fluid traffic model is that it can achieve enormous savings in computing resources when simulating streams of traffic as described above.<br />A change in flow rate signals the event that traffic is fluctuating. Because these changes can occur far less frequently than the arrival of individual cells the computing overhead involved is greatly reduced.<br />31<br />
  32. 32. Auto-regressive and moving average traffic models<br />Auto-regressive traffic models define the next random variable in the sequence X(n) as an explicit function of previous variables within a time window stretching from present to past.<br />Some of the popular auto-regressive models are:<br />Linear auto-regressive processes, AR(p), described as<br />32<br />
  33. 33. Auto-regressive and moving average traffic models<br />Moving average processes, MA(q), described as<br />Auto-regressive moving average processes, ARMA (p, q), described as<br />33<br />
  34. 34. Self-similar traffic models<br />The development of these models were based on the observation that Internet traffic dynamics resulting from interactions among users, applications and protocols, is best represented by the notion of ‘fractals’ a well-established theories with wide applications in physics, biology and image processing.<br />Wavelet modeling offers a powerful and flexible technique for mathematically representing network traffic at multiple time scales. <br />34<br />
  35. 35. Self-similar traffic models<br />A wavelet is a mathematical function having principles similar to that of Fourier analysis;<br /> it is widely used in digital signal processing and image compression techniques.<br />35<br />
  36. 36. The nature of internet traffic<br />Each Internet communication consists of a transfer of information from one computer to another.<br />downloading web pages or sending/receiving emails<br />Packets containing bits of information transmitted over the Internet are the result of simultaneous active communications between two or more computers (usually<br /> termed as hosts) on the Internet.<br />36<br />
  37. 37. The world wide web (WWW)<br />A web page typically consists of multiple elements or objects when downloaded.<br />These objects are loaded using separate HTTP GET requests, serialized in one or more parallel TCP connections to the corresponding server(s).<br />The characteristics of web traffic have been studied over the years to understand the nature of the traffic.<br />37<br />
  38. 38. The world wide web (WWW)<br />One of the key findings is that web traffic comes in bursts, rather than in steady flows, and the same patterns of bursts repeat themselves regardless of whether the time interval studied is a few seconds long or a millionth of a second.<br />This particular type of traffic is called the self-similar or fractal or scale-invariant traffic.<br />38<br />
  39. 39. The world wide web (WWW)<br /> Figure 8.1 illustrates a typical message sequence in a web surf session.<br />39<br />
  40. 40. The world wide web (WWW)<br />Fractals are objects whose appearances are unchanged at different time scales. <br />Essentially, a self-similar process behaves in a similar way over all time scales.<br />Parameters of traffic traces in statistics include <br />size of HTTP files<br />number of files per web page <br />user browsing behavior (user think times and successive document retrievals)<br />The distribution properties of web requests<br />file sizes <br />file popularity<br />40<br />
  41. 41. The world wide web (WWW)<br />Studies indicated that the self-similarity phenomenon is highly variable depending on measurement. <br />It was found that the best distributional model for such highly variable datasets as file sizes and requests inter-arrivals is one with a heavy tail.<br />Processes with heavy-tailed sojourn-time distributions have long-term correlations, also known as long range dependence (LRD). <br />41<br />
  42. 42. The world wide web (WWW)<br />The following formula shows the autocorrelation function of such processes:<br />42<br />
  43. 43. Pareto distribution model for self-similar traffic<br />One of the classes of distributions that are heavy-tailed is the Pareto distribution and its probability distribution function (pdf) is defined as:<br />Its cumulative distribution function (cdf) is given by:<br />43<br />
  44. 44. Pareto distribution model for self-similar traffic<br />The mean and variance of the Pareto distribution are given respectively by:<br />Pareto distribution is a distribution with an infinite variance. A random variable whose distribution has an infinite variance implies that the variable can take on extremely large values with non-negligible probability.<br />44<br />
  45. 45. Fractional Brownian motion (FBM) process<br />The FBM process can be used as the basis of a workload model for generating synthesized self-similar traffic resulting in a simple but useful relationship between the number of customers in the system, q and the system utilization, ρ. <br />Assuming an infinite buffer with a constant service time, this relationship is given as:<br />45<br />
  46. 46. Fractional Brownian motion (FBM) process<br />Using the above relationshipwe plotted the distribution of the average number of packets in the system as a function of the system utilization for a range of H values and compared this with the exponential traffic.<br />46<br />
  47. 47. Fractional Brownian motion (FBM) process<br />Figure 8.2 Comparison between self-similar traffic and exponential traffic<br />47<br />
  48. 48. Fractional Brownian motion (FBM) process<br />We can see that the traces showed the same trend, with a characteristic ‘knee’ beyond which the number of packets increases rapidly.<br />We can also see that as the H parameter value increases, <br />the traffic becomes more self similar, it is difficult to achieve high utilization factors. <br />In order to operate at high system utilization, it requires considerable buffer provisions to avoid overflow. <br />48<br />
  49. 49. Fractional Brownian motion (FBM) process<br />That is to say if we were to design the system according to what is predicted by the exponential traffic<br /> we would not be able to operate at high utilization when subjected to self-similar traffic because the buffer would very quickly overflow.<br />49<br />
  50. 50. Consideration of user behavior in traffic modeling<br />Traffic sources are random or stochastic in nature and the only tool to describe it is in statistical terms. <br />Numerous models have been developed to capture and represent the randomness of this behavior in the form of tractable mathematical equations.<br />50<br />
  51. 51. Consideration of user behavior in traffic modeling<br />Among the traffic, characteristics of interest include <br />arrival rate<br />inter-arrival time<br />Packet sizes<br /> burst<br />duration of connection<br />distribution of arrival times between application invocations. <br />Another important characteristic is<br />the correlation between successive arrivals or between arrivals from different sources.<br />51<br />
  52. 52. Consideration of user behavior in traffic modeling<br />Correlation functions are important measurements<br />used to describe temporal dependencies between sources and bursts of traffic. <br />A temporal or timing relation between sources is especially important in multimedia traffic.<br />The most widely used assumption in modeling these characteristics has considered them as independent identically distributed (iid) random arrival events.<br />52<br />
  53. 53. Consideration of user behavior in traffic modeling<br />User behavior is another important factor that can have an effect on the characteristics of traffic.<br />This is even more so with the explosive growth of the Internet and the corresponding increase in Internet-related traffic. <br />Models, which capture this behavior would be useful to model both <br />packet generation <br />User interaction with applications <br />services by representing the user behavior as a profile.<br />53<br />
  54. 54. Consideration of user behavior in traffic modeling<br />This profile defines a hierarchy of independent processes and different types of stochastic process for modeling these processes. <br />Another related characteristic with regards to Internet or web traffic that is being researched currently is the structure of the web server itself .<br />as this has a bearing on the web page response times which in turn affects the user session.<br />54<br />
  55. 55. Voice traffic modeling<br />Analogue speech is first digitized into pulse code modulation (PCM) signals by a speech/voice codec.<br />Figure 8.3 Packet voice end-to-end flow<br />55<br />
  56. 56. Voice traffic modeling<br />The PCM samples pass on to a compression algorithm, which compresses the voice into packet format prior to transmission on this packet-switched network. <br />At the destination end, the receiver performs the same functions in reverse order.<br />56<br />
  57. 57. Voice traffic modeling<br />Voice applications that utilize IP-based packet networks are commonly referred to as Internet telephony or voice over IP (VoIP).<br />The most distinctive feature of speech signals is that in conversational speech there are alternating periods of signal (speech) and no signal (silence).<br />Human speech consists of an alternating sequence of <br />active interval (during which time one is talking) <br />followed by silence or inactive interval (during which one pauses or listens to the other party).<br />57<br />
  58. 58. Voice traffic modeling<br />The RTP is a media packet protocol for transmitting real-time media data. It provides mechanisms for sending and receiving applications to support streaming data.<br />The MLPPP is an extension of PPP that allows the combination of multiple PPP links into one logical data pipe.<br />58<br />
  59. 59. On-off model for voice traffic<br />It has been widely accepted that modeling packet voice can be conveniently based on mimicking the characteristics of conversation – the alternating active and silent periods.<br />A two-phase on-off process can represent a single packetized voice source.<br />An important characteristic of a voice source to capture is the distribution of these intervals.<br />59<br />
  60. 60. On-off model for voice traffic<br />During the active (on) interval, voice generates fixed size packets with a fixed inter-packet spacing. <br />This is the nature of voice encoders with fixed bit rate and fixed packetization delay.<br />This packet generation process follows a Poisson process with exponentially distributed inter-arrival times of mean T second or packet per second (pps) 1/T.<br />No packets are generated during the silent (off) interval.<br />60<br />
  61. 61. On-off model for voice traffic<br />The mean on period is 1/ α while the mean off period is 1/λ. The mean packet inter arrival time is T s.<br />Figure 8.4 A single voice source, represented by a two-state MMPP<br />61<br />
  62. 62. On-off model for voice traffic<br />This approach can model different voice codec's, with varying mean opinion score (MOS).<br />MOS is a system of grading the voice quality of telephone connections.<br />The mean off interval is typically 650 ms while the mean on interval is 350 ms.<br />62<br />
  63. 63. Video traffic modeling<br />Packet video communication refers to the transmission of digitized and packetized video signals in real time.<br />Video images are represented by a series of frames in which the motion of the scene is reflected in small changes in sequentially displayed frames. <br />Frames are displayed at the terminal at some constant rate (e.g. 30 frames/s) enabling the human eye to integrate the differences within the frame into a moving scene.<br />63<br />
  64. 64. Video traffic modeling<br />There are several factors affecting the nature of video traffic.<br />these are compression techniques<br />coding time (on- or off-line)<br />adaptiveness of the video application<br />supported level of interactivity <br />the target quality (constant or variable)<br />64<br />
  65. 65. Video traffic modeling<br />The output bit rate of the video encoder can either be controlled to produce a constant bit-rate stream which can significantly vary the quality of the video (CBR encoding), or left uncontrolled to produce a more variable bit-rate stream for a more fixed quality video (VBR encoding).<br />Statistical properties of a video stream are quite different from that of voice or data.<br />An important property of video is the correlation structure between successive frames.<br />65<br />
  66. 66. Video traffic modeling<br />Depending on the type of video codec's, video images exhibit the following correlation components:<br />Line correlation is defined as the level of correlation between data at one part of the image with data at the same part of the next line; also called spatial correlation.<br />Frame correlation is defined as the level of correlation between data at one part of the image with data at the same part of the next image; also called temporal correlation.<br />Scene correlation is defined as the level of correlation between sequences of scenes.<br />66<br />
  67. 67. Video traffic modeling<br />Several other measurements are required to characterize video sources as accurately as possible. These measurements include:<br />Autocorrelation function: measures the temporal variations.<br />Coefficient of variation: measures the multiplexing characteristics when variable rate signals are statistically multiplexed.<br />Bit-rate distribution: indicates together with the average bit rate and the variance, an approximate requirement for the capacity.<br />67<br />
  68. 68. Video traffic modeling<br />As mentioned previously, VBR encoded video source is expected to be the dominant video traffic source in the Internet.<br />The models are grouped into four categories<br />Auto-regressive (AR) <br />Markov-based models, <br />Transform expand sample (TES)<br />self-similar and analytical/IID<br />These models were developed based on several attributes of the actual video source.<br />68<br />
  69. 69. Multi-layer modeling for internet WWW traffic<br />The Internet operations consist of a chain of interactions between the users, applications, protocols and the network. <br />This structured mechanism can be attributed to the layered architecture employed in the Internet.<br />The multi-layer modeling approach attempts to replicate the packet generation mechanism as activated by the human users of the Internet and the Internet applications themselves.<br />69<br />
  70. 70. Multi-layer modeling for internet WWW traffic<br />In a multi-layer approach, packets are generated in a hierarchical process.<br />It starts with a human user arriving at a terminal and starting one or more Internet applications.<br />70<br />
  71. 71. Traffic engineering<br />Traffic engineering (TE) is a solution that enables the fulfillment of all those requirements.<br />TE can be regarded as the ability of the network to control traffic flows dynamically in order to prevent congestion, to optimize the availability of resources,<br /> to choose routes for traffic flows while taking into account traffic loads and network state, to move traffic flows towards less congested paths, to react to traffic changes or failures timely.<br />71<br />
  72. 72. Traffic engineering<br />Traffic engineering (TE) has thus emerged as a major<br />consideration in the design and operation of large public Internet backbone networks.<br /> While its beginnings can be traced back to the development of the public switched telephone networks (PSTN).<br />TE is fast finding a more crucial role to play in the design and operation of the Internet.<br />72<br />
  73. 73. Traffic engineering principles<br />Traffic engineering is ‘concerned with the performance optimization of networks’.<br />The main goal of TE is to balance service and cost.<br />The most important task is to calculate the right amount of resources; too much and the cost will be excessive, too little will result in loss of business or lower productivity.<br />As this service/cost balance is sensitive to the changes in business conditions, TE is thus a continuous process to maintain an optimum balance.<br />73<br />
  74. 74. Traffic engineering principles<br />TE is a framework of processes whereby a network’s response to traffic demand and other stimuli such as failure can be efficiently controlled.<br />This framework encompasses:<br />traffic management through control of routing functions and QoSmanagement<br />capacity management through network control;<br />network planning.<br />74<br />
  75. 75. Traffic engineering principles<br />Traffic management ensures that network performance is maximized under all conditions including load shifts and failures.<br />Figure 8.5 The traffic engineering process model<br />75<br />
  76. 76. Traffic engineering principles<br />Another important function of TE is to map traffic onto the physical infrastructure to utilize resources optimally and to achieve good network performance.<br />76<br />
  77. 77. Internet traffic engineering<br />Internet TE is defined as that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks.<br />One of the main goals of Internet TE is to enhance the performance of an operational network, both in terms of traffic handling capability and resource utilization.<br />Another important function is to facilitate reliable network operations.<br />77<br />
  78. 78. Internet traffic engineering<br />Effective TE is difficult to achieve in public IP networks due to the limited functional capabilities of conventional IP technologies.<br />One of the major problems lies in mapping traffic flows onto the physical topology.<br />An initial attempt at circumventing some of the limitations of IP with respect to TE was the introduction of a secondary technology with virtual circuits and traffic management capabilities (such as ATM) into the IP infrastructure.<br />78<br />
  79. 79. Internet traffic engineering<br />ATM was used mainly because of its superior switching performance compared to IP routing at that time.<br />ATM also afforded QoS and TE capabilities. However, there are fundamental drawbacks to this approach.<br />79<br />
  80. 80. Multi-protocol label switching (MPLS)<br />To improve on the best-effort service provided by the IP network layer protocol, new mechanisms such as differentiated services (Diffserv) and integrated services (Intserv), have been developed to support QoS.<br />In the Intservarchitecture, resources have to be reserved for individual services.<br />Flow based techniques such as multi-protocol label switching (MPLS) have also been developed<br />to combine layer 2 and layer 3 functions to support QoS requirements.<br />80<br />
  81. 81. Multi-protocol label switching (MPLS)<br />MPLS introduces a new connection-oriented paradigm, based on fixed-length labels. <br />This fixed-length label-switching concept is similar but not the same as that utilized by ATM.<br />MPLS is a peer model technology.<br />Compared to the overlay model, a peer model integrates layer 2 switching with layer 3 routing, yielding a single network infrastructure. Network nodes would typically have integrated routing and switching functions. <br />81<br />
  82. 82. Multi-protocol label switching (MPLS)<br />This model also allows IP routing protocols to set up ATM connections and do not require address resolution protocols. <br />While MPLS has successfully merged the benefits of both IP and ATM, another application area in which MPLS is fast establishing its usefulness is traffic engineering (TE).<br />82<br />
  83. 83. MPLS forwarding paradigm<br />MPLS is a technology that combines layer 2 switching technologies with layer 3 routing technologies.<br />The primary objective of this new technology is to create a flexible networking fabric that provides increased performance and scalability.<br />This includes TE capabilities.<br />MPLS was initially designed in response to various inter-related problems with the current IP infrastructure.<br />83<br />
  84. 84. MPLS forwarding paradigm<br />Because the concepts of forwarding, switching and routing are fundamental in MPLS, a concise definition of each one of them is given below:<br />Forwarding is the process of receiving a packet on an input port and sending it out on an output port.<br />Switching is forwarding process following the chosen path based information or knowledge of current network resources and loading conditions. <br />Switching operates on layer 2 header information.<br />Routing is the process of setting routes to understand the next hop a packet should take towards its destination within and between networks.<br />It operates on layer 3 header information.<br />84<br />
  85. 85. MPLS forwarding paradigm<br />The conventional IP forwarding mechanism (layer 3 routing) is based on the source destination address pair gleaned from a packet’s header as the packet enters an IP network via a router. <br />The router analyses this information and runs a routing algorithm. <br />The router will then choose the next hop for the packet based on the results of the algorithm calculations.<br />85<br />
  86. 86. MPLS basic operation<br />MPLS tries to solve the problem of integrating the best features of layer 2 switching and layer 3 routing by defining a new operating methodology for the network.<br />MPLS separates packet forwarding from routing.<br />MPLS effectively creates a tunnel underneath the control plane using packet tags called labels.<br />The concept of a tunnel is the key because it means the<br /> forwarding process is no more IP-based and classification at the entry point of an MPLS network is not relegated to IP-only information.<br />86<br />
  87. 87. MPLS basic operation<br />The key concept of MPLS is to identify and mark IP packets with labels. <br />A label is a short, fixed-length, unstructured identifier that can be used to assist in the forwarding process.<br />Labels are analogous to the VPI/VCI used in an ATM network. Labels are normally local to a single data link, between adjacent routers and have no global significance.<br />87<br />
  88. 88. MPLS basic operation<br />A modified router or switch will then use the label to forward/switch the packets through the network. <br />This modified switch/router termed label switching router (LSR) is a key component within an MPLS network. LSR is capable of understanding and participating in both IP routing and layer 2 switching. <br />By combining these technologies into a single integrated operating environment, MPLS avoids the problem associated with maintaining two distinct operating paradigms.<br />88<br />
  89. 89. MPLS basic operation<br />Figure 8.6 Functional components of MPLS<br />89<br />
  90. 90. MPLS basic operation<br />Figure 8.7 MPLS shim header structure<br />90<br />
  91. 91. MPLS basic operation<br />The MPLS forwarding mechanism differs significantly from conventional hop-by-hop routing. <br />The LSR participates in IP routing to understand the network topology as seen from the layer 3 perspective. <br />This routing knowledge is then applied, together with the results of analyzing the IP header, to assign labels to packets entering the network.<br />91<br />
  92. 92. MPLS basic operation<br />There are two ways to set up an LSP<br />control-driven <br />Explicitly routed LSP<br />In the core of the network, LSR ignore the header of network layer packets and simply forward the packet using the label with the label-swapping algorithm. <br />When a labelled packet arrives at a switch, the forwarding component uses the pairing, input port number/incoming interface, incoming label value, to perform an exact match search of its forwarding table.<br />92<br />
  93. 93. MPLS and Diffservinterworking<br />The introduction of a QoS enabled protocol into a network supporting various other QoS protocols would undoubtedly lead to the requirement for these protocols to interwork with each other in a seamless fashion.<br />This requirement is essential to the QoS guarantees to the<br /> packets traversing the network.<br />It is an important issue of interworking MPLS with Diffserv and ATM.<br />93<br />
  94. 94. MPLS and Diffservinterworking<br />The combination of MPLS and Diffserv provides a scheme, which is mutually beneficial for both.<br />Path-oriented MPLS can provide Diffserv with a potentially faster and more predictable path protection and restoration capabilities in the face of topology changes, as compared to conventional hop-by-hop routed IP networks.<br />Diffserv, on the other hand, can act as QoS architecture for MPLS. Combined, MPLS and Diffserv can provide the flexibility to provide different treatments to certain QoS classes requiring path protection.<br />94<br />
  95. 95. MPLS and Diffservinterworking<br />The key issue for supporting Diffserv over MPLS is how to map Diffserv to MPLS.<br />This is because LSR cannot see an IP packet’s header and the associated DSCP values, which links the packet to its BA and consequently to its PHB, as PHB determines the scheduling treatment and, in some cases, the drop probability of a packet. LSR only look for labels, read their contents and decide the next hop.<br />95<br />
  96. 96. MPLS and Diffservinterworking<br />This solution relies on the combined use of two types of LSP:<br />A LSP that can transport multiple ordered aggregates, so that the EXP field of the MPLS shim header conveys to the LSR with the PHB applied to the packet.<br />A LSP that can transport only a single ordered aggregate, so that the LSR exclusively infer the packet scheduling treatment exclusively from the packet label value.<br />96<br />
  97. 97. MPLS and ATM interworking<br />MPLS and ATM can interwork at network edges to support and bring multiple services into the network core of an MPLS domain. In this instance, ATM connections need to be transparent across the MPLS domain over MPLS LSP.<br />There are several requirements that need to be addressed concerning MPLS and ATM interworking. <br />97<br />
  98. 98. MPLS and ATM interworking<br />Some of these requirements are:<br />The ability to multiplex multiple ATM connections (VPC and/or VCC) into an MPLS LSP.<br />Support for the traffic contracts and QoS commitments made to the ATM connections.<br />The ability to carry all the AAL types transparently.<br />Transport of RM cells and CLP information from the ATM cell header.<br />98<br />
  99. 99. MPLS and ATM interworking<br />Transport of ATM traffic over the MPLS uses only the two-level LSP stack. <br />The two-level stack specifies two types of LSP.<br />A transport LSP (T-LSP) transports traffic between two ATM-MPLS interworking devices located at the boundaries of the ATM-MPLS networks.<br />This traffic can consist of a number of ATM connections, each associated with an ATM service category. <br />The outer label of the stack (known as a transport label) defines a T-LSP.<br />99<br />
  100. 100. MPLS and ATM interworking<br />The second type of LSP is an interworking LSP (I-LSP), nested within the T-LSP (identified by an interworking label), which carries traffic associated with a particular ATM connection.<br />I-LSP also provides support for VP/VC switching functions. <br />One T-LSP may carry more than one I-LSP. Because an ATM connection is bi-directional while an LSP is unidirectional, two different I-LSPs, one for each direction of the ATM connection, are required to support a single ATM connection.<br />100<br />
  101. 101. MPLS and ATM interworking<br />Figure 8.8 ATM-MPLS networks interworking. (a) ATM-MPLS network interworking architecture.(b) the relationship between transport LSP, interworking LSP and ATM link<br />101<br />
  102. 102. MPLS and ATM interworking<br />This type of LSP is termed class multiplexed LSP.<br />It groups the ATM service categories into groups and maps each group into a single LSP.<br />It transports the real-time traffic over one T-LSP while the non-real-time traffic over another T-LSP.<br />It can implement class multiplexed LSP by using either L-LSP or E-LSP.<br />102<br />
  103. 103. MPLS and ATM interworking<br />Class multiplexed L-LSP must meet the most stringent QoS requirements of the ATM connections transported by the LSP.<br />This is because L-LSP treats every packet going through it the same.<br />103<br />
  104. 104. MPLS with traffic engineering (MPLS-TE)<br />An MPLS domain still requires IGP such as OSPF and IS-IS to calculate routes through the domain. <br />Once it has computed a route, it uses signaling protocols to establish LSP along the route. <br />Traffic that satisfies a given FEC associated with a particular LSP is then sent down the LSP.<br />104<br />
  105. 105. MPLS with traffic engineering (MPLS-TE)<br />The basic problem addressed by TE is the mapping of traffic onto routes to achieve the performance objectives of the traffic while optimizing the resources at the same time.<br />Conventional IGP such as open shortest path first (OSPF), makes use of pure destination address-based forwarding. <br />It selects routes based on simply the least cost metric.<br />105<br />
  106. 106. MPLS with traffic engineering (MPLS-TE)<br />For TE purposes, the LSR should build a TE database within the MPLS domain. <br />This database holds additional information regarding the state of a particular link.<br />Additional link attributes may include maximum link bandwidth, maximum reserve able bandwidth, current bandwidth utilization, current bandwidth reservation and link affinity or color.<br />106<br />
  107. 107. Internet protocol version 6 (IPv6)<br />Recently, there has been increasing interest in research, development and deployment in IPv6. <br />The protocol itself it very easy to understands. <br />Like any new protocols and networks.<br />107<br />
  108. 108. Basics of internet protocol version 6 (IPv6)<br />The IP version 6 (IPv6), which the IETF have developed as a replacement for the current IPv4 protocol.<br />IPv6 can support integrated services with QoS with such mechanisms and the definition of protocols like RSVP.<br />108<br />
  109. 109. Basics of internet protocol version 6 (IPv6)<br />It extends the IPv4 protocol to address the problems of the current Internet to:<br />support more host addresses<br />reduce the size of the routing table<br />simplify the protocol to allow routers to process packets faster<br />have better security (authentication and privacy)<br />provide QoS to different types of services including real-time data<br />aid multicasting (allow scopes)<br />allow mobility (roam without changing address)<br />allow the protocol to evolve<br />permit coexisting of old and new protocols.<br />109<br />
  110. 110. Basics of internet protocol version 6 (IPv6)<br />The functions of its fields is summarized as the following:<br />The version field has the same function as IPv4. It is 6 for IPv6 and 4 for IPv4.<br />The priority field identifies packets with different real-time delivery requirements.<br />The flow label field is used to allow source and destination to set up a pseudo-connection with particular properties and requirements.<br />The payload field is the number of bytes following the 40-byte header, instead of total length in IPv4.<br />110<br />
  111. 111. Basics of internet protocol version 6 (IPv6)<br />The next header field tells which transport handler to pass the packet to, like the protocol field in the IPv4.<br />The hop limit field is a counter used to limit packet lifetime to prevent the packet staying in the network forever, like the time to live field in IPv4.<br />The source and destination addresses indicate the network number and host number, four times larger than IPv4.<br />There are also extension headers like the options in IPv4.<br />111<br />
  112. 112. Basics of internet protocol version 6 (IPv6)<br />IPv6 tries to achieve an efficient and extensible IP datagram in that:<br />the IP header contains less fields that enable efficient routing and performance<br />extensibility of header offers better options<br />the flow label gives efficient processing of IP datagram.<br />112<br />
  113. 113. IPv6 addressing<br />IPv6 has introduced a large addressing space to address the shortage of IPv4 addresses. <br />It uses 128 bits for addresses, four times the 32 bits of the current IPv4 address.<br />It allows about 34×10 possible addressable nodes, equivalent to 1030 addresses per person on the planet. <br />Therefore, we should never exhaust IPv6 addresses in the future Internet.<br />113<br />
  114. 114. IPv6 addressing<br />In IPv6, there is no hidden network and host. <br />All hosts can be servers and are reachable from outside. This is called global reach ability.<br />The aggregatable global address is for generic use and allows globally reach. <br />The address is allocated by IANA (Internet assigned number authority) with a hierarchy of tier-1 providers<br /> as top-level aggregator (TLA), intermediate providers as next-level aggregator (NLA), and finally sites and subnets at the bottom.<br />114<br />
  115. 115. IPv6 addressing<br />Structure of the aggregatable global address<br />Some reserved multicast addresses<br />115<br />
  116. 116. IPv6 addressing<br />loop back address;<br />all-nodes multicast address;<br />solicited-node multicast address for each of its assigned unicast and anycast address;<br />multicast address of all other groups to which the host belongs.<br />116<br />
  117. 117. IPv6 networks over satellites<br />Satellite network is IPv6 enabled:<br />this raises issues on user terminals and terrestrial IP networks. We can imagine that it is not practical to upgrade them all at the same time. Hence, one of the great challenges is how to evolve from current IP networking over satellite towards the next generation network over satellites. <br />Tunneling from IPv4 to IPv6 or from IPv6 to IPv4 is inevitable, hence generating great overheads. Even if all networks are IPv6 enabled, there is still a bandwidth efficiency problem due to the large overhead of IPv6.<br />117<br />
  118. 118. IPv6 networks over satellites<br />Satellite network is IPv4 enabled:<br />this faces similar problems to the previous scenario, however, satellite networks may be forced to evolve to IPv6 if all terrestrial networks and terminals start to run IPv6. In terrestrial networks when bandwidth is plentiful, we can afford to delay the evolution. In satellite networks, such a strategy may not be practical.<br />Hence, timing, stable IPv6 technologies and evolution strategies all play an important role.<br />118<br />
  119. 119. IPv6 transitions<br />The transition of IPv6 towards next-generation networks is a very important aspect. Many new technologies failed to succeed because of the lack of transition scenarios and tools.<br /> IPv6 was designed with transition in mind from the beginning. For end systems, it uses a dual stack approach.<br />119<br />
  120. 120. IPv6 transitions<br />Illustration of dual stack host<br />120<br />
  121. 121. IPv6 tunneling through satellite networks<br />Tunnelling IPv6 in IPv4 is a technique use to encapsulate IPv6 packets into IPv4 packets with protocol field 41 of the IP packet header.<br />The tunnel endpoints take care of the encapsulation. This process is ‘transparent’ to the intermediate nodes. Tunnelling is one of the most vital transition mechanisms.<br />Tunnel configuration cases can be between two hosts, one host and one router<br />121<br />
  122. 122. The 6to4 translation via satellite networks<br />The 6to4 translation is a technique used to interconnect isolated IPv6 domains over an IPv4 network with automatic establishment of a tunnel. <br />It avoids the explicit tunnels used in the tunnelling technique by embedding the IPv4 destination address in the IPv6 address.<br />122<br />
  123. 123. The 6to4 translation via satellite networks<br />Encapsulation of IPv6 packet into IPv4 packet<br />123<br />
  124. 124. The 6to4 translation via satellite networks<br />Host to router tunnelling through satellite access network<br />124<br />
  125. 125. The 6to4 translation via satellite networks<br />Router to router tunnelling through satellite core network<br />125<br />
  126. 126. The 6to4 translation via satellite networks<br />The 6to4 translation via satellite access network<br />126<br />
  127. 127. The 6to4 translation via satellite networks<br />The 6to4 translation via satellite core network<br />127<br />
  128. 128. Issues with 6to4<br />IPv4 external address space is much smaller than IPv6 address space.<br />If the egress router changes its IPv4 address, then it means that the full IPv6 internal network needs to be renumbered. <br />There is only one entry point available. It is difficult to have multiple network entry points to include redundancy.<br />128<br />
  129. 129. Issues with 6to4<br />The application transitions of different cases can be summarized as the following:<br />For IPv4 applications in a dual-stack node, the first priority is to port applications to IPv6.<br />For IPv6 applications in a dual-stack node, use IPv4-mapped IPv6 address ‘::FFFF:x.y.z.w’ to make IPv4 applications work in IPv6 dual stack.<br />For IPv4/IPv6 applications in a dual-stack node, it should have a protocol-independent API.<br />For IPv4/IPv6 applications in an IPv4-only node, it should be dealt with on a case-by-case basis, depending on applications/OS support.<br />129<br />
  130. 130. Future development of satellite networking<br />It is difficult to predict the future, sometime impossible, but it is not too difficult to predict the trends towards future development if we have enough past and current knowledge. <br />In addition to integrating satellites into the global Internet infrastructure, one of the major tasks is to create new services and applications to meet the needs of people.<br />130<br />
  131. 131. Future development of satellite networking<br />IPv6 application transitions<br />131<br />
  132. 132. Future development of satellite networking<br />An illustration of future development of satellite networking<br />132<br />
  133. 133. Future development of satellite networking<br />The main difficulties are due to evolution, integration and convergence:<br />It becomes difficult to separate satellite networking concepts from others.<br />It will not be easy to tell the differences between protocols and satellite-friendly protocols due to network convergence except in the physical and link layers.<br />The trends are due to the following reasons:<br />The services and applications will converge to common applications for both satellite networking terminals and terrestrial mobile networking terminals. Even satellite-specific services such as global positioning systems (GPS) have been integrated with the new generation of 2.5G and 3G mobile terminals.<br />133<br />
  134. 134. Future development of satellite networking<br />The hardware platforms and networking technologies will be well developed, powerful and standardized. This will allow quick and economic development of specialized user terminals.<br />We will see significant development in system software, and face the challenge of managing complexity of large software.<br />134<br />
  135. 135. Further reading<br />[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and Swallow, G., RSVP-TE: extensions to RSVP for LSP tunnels, IETF RFC 3209, December 2001.<br />[2] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and Xiao. X., Overview and principles of Internet traffic engineering, IETF RFC 3272 (informational), May 2002.<br />[3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and Weiss, W., An architecture for differentiated services, IETF RFC 2475 (informational), December 1998.<br />[4] Braden, R., Clark, D. and Shenker, S., Integrated services in the Internet architecture: an overview, IETF RFC1633 (informational), June 1994.<br />135<br />
  136. 136. Further reading<br />[5] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification, IETF RFC 2205 (standard track), September 1997.<br />[6] Bradner, S. and Mankin, A., The recommendation for the IP next generation protocol, IETF RFC 1752 (standard track), January 1995.<br />[7] Davie, B., Lawrence, J., McCloughrie, K., Rosen, E., Swallow, G., Rekhter, Y. and Doolan, P., MPLS using LDP and ATM VC switching, IETF RFC 3035 (standard track), January 2001.<br />[8] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J-Y., Courtney, W., Davari, S., Firoiu, V. and Stiliadis, D., An expedited forwarding PHB (per hop behaviour), IETF RFC 3246 (proposed standard), March2002.<br />136<br />
  137. 137. Further reading<br />[9] Deering, S. and Hinden, R., Internet protocol, version 6 (IPv6) specification, IETF RFC 2460 (standard track), December 1998.<br />[10] Faucheur, F. Le, Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and Heinanen, J., Multi-protocol label switching (MPLS) support of differentiated services, IETF RFC 3270 (standard track), May 2002.<br />[11] Gilligan, R. and Nordmark, E., Transition mechanisms for IPv6 hosts and routers, IETF RFC 2893 (standard track), August 2000.<br />[12] Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J., Assured forwarding PHB group, RFC 2597 (standard track), June 1999.<br />137<br />
  138. 138. Further reading<br />[13] ISO/IEC 11172, Coding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbit/s, 1993.<br />[14] ISO/IEC 13818, Generic coding of moving pictures and associated audio information, 1996.<br />[15] ISO/IEC 14496, Coding of audio-visual objects, 1999.<br />[16] ITU-T G.723.1, Speech coders: Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s, 1996.<br />[17] ITU-T G.729, Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction(CS-ACELP), 1996.<br />[18] ITU-T E.800, Terms and definitions related to quality of service and network performance including dependability,1994.<br />138<br />
  139. 139. Further reading<br />[19] ITU-T H.261, Video codec for audiovisual services at px64 kbit/s, 1993.<br />[20] ITU-T H.263, Video coding for low bit rate communication, 1998.<br />[21] Marot, M., Contributions to the study of traffic in networks, PhD thesis, INT and University of Paris VI, France, 2001.<br />[22] Nichols, K., Blake, S., Baker, F. and Black, D., Definition of the differentiated services field (DS field) in the IPv4 and IPv6 headers, IETF RFC 2474 (standard track), December 1998.<br />[23] RFC2375, IPv6 Multicast address assignments, R. Hinden, July 1998.<br />[24] RFC2529, Transmission of IPv6 over IPv4 domains without explicit tunnels, B. Carpenter, C. Jung, IETF, March 1999.<br />139<br />
  140. 140. Further reading<br />[25] RFC2766, Network address translation – protocol translation (NAT-PT), G. Tsirtsis, P. Srisuresh, IETF, February 2000.<br />[26] RFC2767, Dual stack hosts using the ‘bump-in-the-stack’ technique (BIS), K. Tsuchiya, H. Higuchi,Y. Atarashi, IETF, 2000-02-01,<br />[27] RFC2893, Transition mechanisms for IPv6 hosts and routers, R. Gilligan, E.Nordmark, 2000-08-01<br />[28] Rosen, E., Viswanathan, A. and Callon, R., Multiprotocol label switching architecture, IETF RFC 3031 (standard track), January 2001.<br />140<br />
  141. 141. Further reading<br />[29] Salleh, M., New generation IP quality of service over broadband networks, PhD thesis, University of Surrey,UK, 2004.<br />[30] Sánchez, A., Contribution to the study of QoS for real-time multimedia services over IP networks, PhD thesis,Universityof Valladolid, Spain, 2003.<br />[31] Shenker, S., Partridge, C. and Guerin, R., Specification of guaranteed quality of service, IETF RFC 2212 (standard track), September 1997.<br />141<br />
  142. 142. Thank You !<br />142<br />