1 / 58

Optical Core Networks GMPLS - advanced

Optical Core Networks GMPLS - advanced. Piero Castoldi, Scuola Superiore Sant’Anna, castoldi@sssup.it. Outline. GMPLS Summary Peculiarity GMPLS protocol suite OSPF-TE RSVP-TE LMP Advanced internetworking models Overlay model Peer model Augmented model. GMPLS

necia
Télécharger la présentation

Optical Core Networks GMPLS - advanced

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Optical Core NetworksGMPLS - advanced Piero Castoldi, Scuola Superiore Sant’Anna, castoldi@sssup.it

  2. Outline • GMPLS • Summary • Peculiarity • GMPLS protocol suite • OSPF-TE • RSVP-TE • LMP • Advanced internetworking models • Overlay model • Peer model • Augmented model

  3. GMPLS Generalized Multiprotocol Label Switching Summary

  4. GMPLS Key Features (1) • Dynamic and Distributed LSP Explicit TE-Route Computation (in the past: simulation, manual planning and human action) • Dynamic and Distributed LSP Setup/ Deletion/ Modification (in the past: manual and step-by-step provisioning – does not provide “bandwidth on demand” capability) • Network resource optimization with multi-layer traffic-engineering and protection/restoration (in the past: provisioned model implies at least waste of 40% - 60% network resources) • Per-LSP (per-LSP Group) Fast Restoration in 200ms to < 1s (in the past: centralized computation based on restricted scenarios implying restoration time > 5s) and Signalled Protection in < 50ms (as specified in ITU-T G.841)

  5. GMPLS Key Features (2) • GMPLS supports • re-use MPLS-TE as “non-packet” LSP control plane • “lightpath” definition of switched path (label space values: wavelengths) • generalize Address Prefix to “non-packet” terminating interfaces • generalize TE concept to “non-packet” resources • GMPLS control plane architecture includes several extended MPLS-TE building blocks: • Signalling Protocols: RSVP-TE (and CR-LDP) • Intra-domain Routing Protocols: OSPF-TE (and ISIS-TE) • Link Management Protocol (LMP): new • TE-Routing enhanced scalability and flexibility • Link Bundling (TE-Links) • Generalized Unnumbered interfaces

  6. Switching Diversity • Generalized Label • Contains information to allow the receiving device to program its switch and forward data regardless of its construction (packet, TDM, lambda, etc) • A generalized label can represent a single wavelength, a single fiber, or a single time-slot. • Information in a generalized label includes: • LSP encoding type that indicates what type of label is being carried (e.g., packet, lambda, SONET, etc.) • Switching type that indicates whether the node is capable of switching packets, time-slot, wavelength, or fiber

  7. LSP Creation in GMPLS-Based NetworksHierarchical LSP 1.    LSP (LSPλ) is established between OXC1 and OXC2 and capable of delivering OC-192 wavelength to tunnel in TDM LSPs. 2.      LSP (LSPtdi) is established between DCSi and DCSe. 3.      LSP (LSPtdm) is established between DCS1 and DCS2. 4.      LSP (LSPpi) is established between LSR2 and LSR3 (LSPpi). 5. LSP (LSPpc) is established between LSR1 and LSR4.

  8. GMPLS Generalized Multiprotocol Label Switching Peculiarities

  9. Forwarding Diversity • MPLS devices are capable of discerning the contents-of-information unit that is passed between them—e.g., a packet or a cell that has header information. • They need to examine the label (e.g., shim header) to determine the output port and the output label for an incoming packet. • The label-swapping paradigm logically separates the data and the control planes. • GMPLS extends this paradigm to those devices that are not designed to lookup any headers when they receive the user data. In this case, GMPLS allows the data plane and the control plane to be physically and logically separated. • For example, the control path between two devices could travel an external line such as an Ethernet connection, or other types of physical links. • GMPLS does not mandate how the control information is to be transported between two nodes.

  10. Scalability (1) • Forwarding Adjacency – LSP (FA-LSP) • A FA–LSP is a GMPLS–based LSP to carry other LSPs. • An FA–LSP established between two GMPLS nodes can be viewed as a virtual link with its own traffic-engineering characteristics and can be advertised into the OSPF/IS–IS as a normal link like any other physical link. • An FA–LSP may be incorporated into the link-state database and used in routing-path calculation to carry other LSPs. This can reduce the size of the database, and, consequently, the time that is spent in the table look-up operation.

  11. Scalability (2) FA concept: a TDM LSP can be viewed as a single link between the packet-based LSRs of the two PSC network, instead of all the physical links in the TDM network

  12. Scalability (3) - Hierarchical LSP • The network hierarchy (access, metro, and long haul) shown provides an increasing bandwidth capacity per hierarchy. • When an end-to-end flow is to be establish for a particular enterprise application, that flow will traverse networks that use devices that may not be designed to configure connections with flexible bandwidth levels—i.e., only discrete bandwidth are available. • It is better to aggregate lower-speed flows into higher-speed ones. This brings the notion of hierarchical LSP

  13. Scalability (4) - Hierarchical LSP Bandwidth that remains within each LSP can and should be used to accept and include additional LSPs from lower-hierarchy LSPs

  14. Link Bundling (1) • It is expected that an optical network will deploy tens to hundreds of parallel fibers, each carrying hundreds to thousands of lambdas between two nodes. • To avoid a large size for the link database and provide better scaling of the network, GMPLS has introduced the concept of link bundling. • Link bundling allows the mapping of several links into one and advertising that into the routing protocol—i.e., OSPF, IS–IS. • Although, with the increased level of abstraction, some information is lost, this method greatly lowers the size of the link-state database and the number of links that need to be advertised.

  15. Link Bundling (2) • GMPLS flexibly allows the bundling of both point-to-point (PTP) links and LSPs that were advertised as links to OSPF (forward adjacency). • There are restrictions in bundling links: • All links that comprise a bundled link must begin and end on the same pair of LSRs. • All links that comprise a bundled link must be of the same link type (e.g. PTP or multicast). • All links that comprise a bundled link must have the same traffic metric (e.g., protection type or bandwidth). • All links that comprise a bundled link must have the same switching capability—PSC, TDMC, LSC, or FSC.

  16. Reliability • A key attribute of GMPLS suite of protocols is the ability to enable automated fault management in network operation. • A fault in one type of the network must be isolated and resolved separately from other networks. This is a very important feature for end-to-end LSPs that are tunneled in other LSPs that require higher degrees of reliability along the hierarchy. • A common control plane that spans dissimilar networks must be able to address the varying degrees of reliability requirements within each network span.

  17. Fault Management • LMP handles the • localization procedure • by sending LMP ChannelFail • messages over a control channel, followed by ChannelFailAck or ChannelFailNack - Handled by physical or optical layer - Loss of Light - Other techniques • LMP may notify the node responsible for restoration • RSVP-TE notify messages for LSP failures between non-neighboring nodes • Switchover failed path to re-allocated LSP (fast switchover – protection) or create a new path for the LSP dynamically (restoration)

  18. Resilience mechanisms supported by GMPLS

  19. Security • Traditional IP routing examines the contents of the header of a received packet to determine the next hop for it. • While time-consuming, this step allows the establishment of firewalls, as the necessary information is available in the packet header—e.g., the source and the destination addresses that are globally unique. • In contrast, GMPLS/MPLS labels are used to speed up the forwarding scheme and only have local significance—i.e., the label is only understood and used internally by the GMPLS device itself. • As such, these labels cannot be used for access-control or network-security purposes.

  20. Network equilibrium • When a new resource is deleted or added in a GMPLS network, the set of control information that is exchanged is larger than that of a traditional IP network. • GMPLS uses traffic-engineering models that include introducing a set of traffic parameters, associated with data links, performing constraints-based routing, LMPs, etc. • An MPLS/GMPLS network takes a relatively longer time to achieve an equilibrium state than a traditional IP network when the network is disrupted.

  21. GMPLS Generalized Multiprotocol Label Switching Operation

  22. The GMPLS protocol suite • Routing protocol: Open Shortest Path First with Traffic Engineering Extensions (OSPF-TE). It carries extensions to describe the Traffic Engineering topology of the network. • Signaling protocol: ReserVation Protocol with Traffic Engineering Extensions (RSVP-TE). It carries information about the label to be allocated • Physical link management: Link Management Protocol (LMP).

  23. Routing protocol with TE • TE-enabling link characteristics • traffic engineering metric, e.g.: • delay, delay variation, loss • maximum bandwidth, i.e.: • nominal bandwidth of a link • maximum reservable bandwidth; allows to specify: • over-provisioning • over-subscription • resource class/color • a bit mask that determines to which class(es) a link belongs (e.g., satellite link, link that can be used only by selected users, link with special pricing)

  24. Opaque LSA Format for OSPF-TE (1)

  25. Opaque LSA Format for OSPF-TE (2)

  26. OSPF-TE - Opaque LSA Payload

  27. OSPF-TE - Opaque LSA- Link sub TLV

  28. GMPLS Signalling (1) • Downstream on demand Label Allocation • Ingress LSR initiated Ordered Control • Liberal Label retention mode (conservative not excluded) • Label distribution protocol • Supports label assignment and distribution • Traffic engineering support • Explicitly routed LSPs • Pre-emption • Loop detection

  29. GMPLS Signalling (2) • Ingress node initiates setup with PATH message (label request) • PATH message(LABEL_REQUEST object) • Labels are allocated downstream • Labels are distributed upstream (label binding) • RESV message (LABEL object)

  30. Traffic Engineering Support • EXPLICIT_ROUTE object in Path messages • Includes route for LSP • Route determined by ingress LSR • Manually configured • Automatically computed • QoS requirements • Policy constraints

  31. Route • Strict route • Lists all the nodes to be traversed • Loose route • Lists some of the nodes to be traversed • Traditional routing is used between subsequent nodes

  32. RSVP-TE format (1) • RSVP is flexible and customizable • Messages is based on objects • Same concept as TLV 4 bytes

  33. RSVP-TE format (2) Object fields • Length • Always a multiple of 4 • At least 4 • Class-num • Identifies the object’s class • A few are universally known • C-type • Type of object

  34. RSVP-TE format (3) Header Object 1 Object 2 Object n • Header of RSVP-TE message 4 bytes

  35. RSVP-TE format (4) Message types • Path • Resv • PathErr • ResvErr • PathTear • ResvTear • ResvConf

  36. Label set • The label set is used to limit the label choice of a downstream node to a set of acceptable labels • The receiver must restrict its choice of labels to one which is in the label set • There are four cases where a label set is useful in the optical domain • Case 1: the end equipment is only capable of transmitting/receiving on a small specific set of wavelengths • Case 2: there is a sequence of interfaces that cannot support wavelength conversion and require the same wavelength to be used over a sequence of hops • Case 3: Limit the number of wavelength conversion along the path • Case 4: two ends of a link support different sets of wavelengths

  37. Suggested Label • This is used to provide a downstream node with the upstream node’s label preference. • This permits the upstream node to start configuring its hardware with the proposed label before the label is communicated by the downstream node (useful if time to configure a label is non-trivial) • It can be overriden by the downstream node • Other use of the label set have been designed in the recent years

  38. Label preference with Suggested Label (1) l1 l3 l1 l2 l4 l1 l3 l4 Label Set = PATH PATH PATH l1 Asource B C Ddest SL computing algorithm Label reservation algorithm l2 l3 • At destination, reserve the received SL and propagate it as far as possible • If a conversion is needed, reserve the received SL if available, otherwise reserve an available label • Select the previous hop suggested label • Otherwise, select a label not requiring wavelength conversion in the node • Otherwise, select an available label l4 RESV RESV RESV l1 l1 l1 • Standard optional object designed for WRON, included in PATH message • Normal use: provisioning speed up with slow switching devices • Novel use: assign preference to a label ensuring a wavelength-continuous path Sugg. Label = l2 l1 l1

  39. Label preference with Suggested Label (2) l1 l3 l1 l2 l4 l1 l3 l4 Label Set = PATH PATH PATH l1 Asource B C Ddest SL computing algorithm Label reservation algorithm l2 l3 • At destination, reserve the received SL and propagate it as far as possible • If a conversion is needed, reserve the received SL if available, otherwise reserve an available label • Select the previous hop suggested label • Otherwise, select a label not requiring wavelength conversion in the node • Otherwise, select an available label l4 RESV RESV RESV l3 l2 l3 • Standard optional object designed for WRON, included in PATH message • Normal use: provisioning speed up with slow switching devices • Novel use: in this example assign preference to a label ensuring a wavelength-continuous path Sugg. Label = l2 l4 l3 WavelengthConversion

  40. Tie-breaking policies l1 l3 l4 l3 Random policy First-fit policy Nodes unaware of label utilization on remote links Only policies requiring node-local information can be exploited • Specify the behavior of the nodes whenthey need to choose a label within a pool of labels with equal ranking • Used during Suggested Label computation and label reservation • Local matter of each node, no standard behavior is needed (i.e., left to implementation)

  41. Label preference with Suggested Vector Suggested Vector l1 l3 l1 l2 l4 l1 l3 l4 Label Set = PATH PATH PATH l1 Label reservation algorithm Asource B C Ddest l2 SV computing algorithm • At destination, reserve the label with minimum received SV and propagate it as far as possible • If a conversion is needed, reserve the label with minimum received SV l3 l4 • Source node: 0 for any label (no WC) • Intermediate nodes: same value for labels available on the previous hop, otherwise minimum received SV + 1 RESV RESV RESV l1 l1 l1 • Novel optional object included in PATH message • Indicates the preference level for each wavelength within the Label Set • General purpose: allows to rank wavelengths according to a given preference metric 0 1 0 0 0 0 1 0 In this example SV contains the number of conversions needed to use the corresponding label

  42. Link Management Protocol NODE A NODE B … as before …

  43. GMPLS Generalized Multiprotocol Label Switching Advanced topics

  44. Optical UNI & NNI • GMPLS does not separately specify User Network (UNI) or Network-Network (NNI) interfaces • UNI: interface between user and a network cloud • NNI: interface between two networks • GMPLS can be used as a UNI or NNI but IETF not specifically defined how • IETF has defined a UNI using GMPLS, OIF has defined its own UNI

  45. UNI Functional Task UNI NNI Abstracted Topology Actual Topology

  46. NNI Functional Task UNI NNI Abstracted Topology Actual Topology

  47. UNI interface – Mode of operation 1. Overlay Model • Allows separate control mechanisms to be used. • One network is “over” a lower level technology. • MPLS LSP’s send traffic through this lower level technology. 2. Peer Model • Uses GMPLS control functions at all levels. • To control fiber selection, wavelength selection, up to packet level. • Creates a unified control plane - no more IP/MPLS over optical, etc. 3. Augmented Model • A combination of the two can be used, depending on the location in the network, creating a “hybrid” model

  48. The overlay model • Features • One network is “over” a lower level technology – IP/MPLS client, WDM server • MPLS LSP’s send traffic through this lower level technology • Separate IP/MPLS and WDM control planes • The edge IP/MPLS routers interact with the optical network via a UNI (User to Network Interface) • Routing within the optical network is independent to that within the IP/MPLS networks - allows separate control mechanisms to be used. • Core OXC are not seen as network nodes

  49. Routing in overlay mode: “overlay routing” • Routing within the IP/MPLS network and the optical network are separate • The optical network provides switched or permanent lightpaths (and sub-channels) between edge routers • An edge router requests a lightpath/sub-channel from its ingress OXC (i.e. the switch to which it is attached) using a signalling protocol over the UNI. • Protocols for the UNI have been defined within IETF, OIF and ITU-T • Signalling messages are provided for: • Creating, deleting and modifying a lightpath and status enquiry

  50. UNI Interface: Overlay model • Characteristic: • Client IP/MPLS networks request “black-box” services from the optical network • Client IP/MPLS networks and optical network protocols are separated • Benefits • Simple to specify, implement and deploy • Separation provides failure isolation, independent evolution • Hides service providers’ optical topology from its customer

More Related