diff options
Diffstat (limited to 'doc/rfc/rfc3945.txt')
| -rw-r--r-- | doc/rfc/rfc3945.txt | 3867 |
1 files changed, 3867 insertions, 0 deletions
diff --git a/doc/rfc/rfc3945.txt b/doc/rfc/rfc3945.txt new file mode 100644 index 0000000..4aecc8c --- /dev/null +++ b/doc/rfc/rfc3945.txt @@ -0,0 +1,3867 @@ + + + + + + +Network Working Group E. Mannie, Ed. +Request for Comments: 3945 October 2004 +Category: Standards Track + + + Generalized Multi-Protocol Label Switching (GMPLS) Architecture + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + Future data and transmission networks will consist of elements such + as routers, switches, Dense Wavelength Division Multiplexing (DWDM) + systems, Add-Drop Multiplexors (ADMs), photonic cross-connects + (PXCs), optical cross-connects (OXCs), etc. that will use Generalized + Multi-Protocol Label Switching (GMPLS) to dynamically provision + resources and to provide network survivability using protection and + restoration techniques. + + This document describes the architecture of GMPLS. GMPLS extends + MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), + wavelength (lambdas), and spatial switching (e.g., incoming port or + fiber to outgoing port or fiber). The focus of GMPLS is on the + control plane of these various layers since each of them can use + physically diverse data or forwarding planes. The intention is to + cover both the signaling and the routing part of that control plane. + + + + + + + + + + + + + + + +Mannie Standards Track [Page 1] + +RFC 3945 GMPLS Architecture October 2004 + + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Acronyms & Abbreviations. . . . . . . . . . . . . . . . 4 + 1.2. Multiple Types of Switching and Forwarding Hierarchies. 5 + 1.3. Extension of the MPLS Control Plane . . . . . . . . . . 7 + 1.4. GMPLS Key Extensions to MPLS-TE . . . . . . . . . . . . 10 + 2. Routing and Addressing Model. . . . . . . . . . . . . . . . . 11 + 2.1. Addressing of PSC and non-PSC layers. . . . . . . . . . 13 + 2.2. GMPLS Scalability Enhancements. . . . . . . . . . . . . 13 + 2.3. TE Extensions to IP Routing Protocols . . . . . . . . . 14 + 3. Unnumbered Links. . . . . . . . . . . . . . . . . . . . . . . 15 + 3.1. Unnumbered Forwarding Adjacencies . . . . . . . . . . . 16 + 4. Link Bundling . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.1. Restrictions on Bundling. . . . . . . . . . . . . . . . 17 + 4.2. Routing Considerations for Bundling . . . . . . . . . . 17 + 4.3. Signaling Considerations. . . . . . . . . . . . . . . . 18 + 4.3.1. Mechanism 1: Implicit Indication. . . . . . . . 18 + 4.3.2. Mechanism 2: Explicit Indication by Numbered + Interface ID. . . . . . . . . . . . . . . . . . 19 + 4.3.3. Mechanism 3: Explicit Indication by Unnumbered + Interface ID. . . . . . . . . . . . . . . . . . 19 + 4.4. Unnumbered Bundled Link . . . . . . . . . . . . . . . . 19 + 4.5. Forming Bundled Links . . . . . . . . . . . . . . . . . 20 + 5. Relationship with the UNI . . . . . . . . . . . . . . . . . . 20 + 5.1. Relationship with the OIF UNI . . . . . . . . . . . . . 21 + 5.2. Reachability across the UNI . . . . . . . . . . . . . . 21 + 6. Link Management . . . . . . . . . . . . . . . . . . . . . . . 22 + 6.1. Control Channel and Control Channel Management. . . . . 23 + 6.2. Link Property Correlation . . . . . . . . . . . . . . . 24 + 6.3. Link Connectivity Verification. . . . . . . . . . . . . 24 + 6.4. Fault Management. . . . . . . . . . . . . . . . . . . . 25 + 6.5. LMP for DWDM Optical Line Systems (OLSs). . . . . . . . 26 + 7. Generalized Signaling . . . . . . . . . . . . . . . . . . . . 27 + 7.1. Overview: How to Request an LSP . . . . . . . . . . . . 29 + 7.2. Generalized Label Request . . . . . . . . . . . . . . . 30 + 7.3. SONET/SDH Traffic Parameters. . . . . . . . . . . . . . 31 + 7.4. G.709 Traffic Parameters. . . . . . . . . . . . . . . . 32 + 7.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 33 + 7.6. Generalized Label . . . . . . . . . . . . . . . . . . . 34 + 7.7. Waveband Switching. . . . . . . . . . . . . . . . . . . 34 + 7.8. Label Suggestion by the Upstream. . . . . . . . . . . . 35 + 7.9. Label Restriction by the Upstream . . . . . . . . . . . 35 + 7.10. Bi-directional LSP. . . . . . . . . . . . . . . . . . . 36 + 7.11. Bi-directional LSP Contention Resolution. . . . . . . . 37 + 7.12. Rapid Notification of Failure . . . . . . . . . . . . . 37 + 7.13. Link Protection . . . . . . . . . . . . . . . . . . . . 38 + 7.14. Explicit Routing and Explicit Label Control . . . . . . 39 + + + +Mannie Standards Track [Page 2] + +RFC 3945 GMPLS Architecture October 2004 + + + 7.15. Route Recording . . . . . . . . . . . . . . . . . . . . 40 + 7.16. LSP Modification and LSP Re-routing . . . . . . . . . . 40 + 7.17. LSP Administrative Status Handling. . . . . . . . . . . 41 + 7.18. Control Channel Separation. . . . . . . . . . . . . . . 42 + 8. Forwarding Adjacencies (FA) . . . . . . . . . . . . . . . . . 43 + 8.1. Routing and Forwarding Adjacencies. . . . . . . . . . . 43 + 8.2. Signaling Aspects . . . . . . . . . . . . . . . . . . . 44 + 8.3. Cascading of Forwarding Adjacencies . . . . . . . . . . 44 + 9. Routing and Signaling Adjacencies . . . . . . . . . . . . . . 45 + 10. Control Plane Fault Handling. . . . . . . . . . . . . . . . . 46 + 11. LSP Protection and Restoration. . . . . . . . . . . . . . . . 47 + 11.1. Protection Escalation across Domains and Layers . . . . 48 + 11.2. Mapping of Services to P&R Resources. . . . . . . . . . 49 + 11.3. Classification of P&R Mechanism Characteristics . . . . 49 + 11.4. Different Stages in P&R . . . . . . . . . . . . . . . . 50 + 11.5. Recovery Strategies . . . . . . . . . . . . . . . . . . 50 + 11.6. Recovery mechanisms: Protection schemes . . . . . . . . 51 + 11.7. Recovery mechanisms: Restoration schemes. . . . . . . . 52 + 11.8. Schema Selection Criteria . . . . . . . . . . . . . . . 53 + 12. Network Management. . . . . . . . . . . . . . . . . . . . . . 54 + 12.1. Network Management Systems (NMS). . . . . . . . . . . . 55 + 12.2. Management Information Base (MIB) . . . . . . . . . . . 55 + 12.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . 56 + 12.4. Fault Correlation Between Multiple Layers . . . . . . . 56 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 57 + 14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58 + 15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 58 + 15.1. Normative References. . . . . . . . . . . . . . . . . . 58 + 15.2. Informative References. . . . . . . . . . . . . . . . . 59 + 16. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 63 + 17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 68 + Full Copyright Statement. . . . . . . . . . . . . . . . . . . 69 + + + + + + + + + + + + + + + + + + + +Mannie Standards Track [Page 3] + +RFC 3945 GMPLS Architecture October 2004 + + +1. Introduction + + The architecture described in this document covers the main building + blocks needed to build a consistent control plane for multiple + switching layers. It does not restrict the way that these layers + work together. Different models can be applied, e.g., overlay, + augmented or integrated. Moreover, each pair of contiguous layers + may collaborate in different ways, resulting in a number of possible + combinations, at the discretion of manufacturers and operators. + + This architecture clearly separates the control plane and the + forwarding plane. In addition, it also clearly separates the control + plane in two parts, the signaling plane containing the signaling + protocols and the routing plane containing the routing protocols. + + This document is a generalization of the Multi-Protocol Label + Switching (MPLS) architecture [RFC3031], and in some cases may differ + slightly from that architecture since non packet-based forwarding + planes are now considered. It is not the intention of this document + to describe concepts already described in the current MPLS + architecture. The goal is to describe specific concepts of + Generalized MPLS (GMPLS). + + However, some of the concepts explained hereafter are not part of the + current MPLS architecture and are applicable to both MPLS and GMPLS + (i.e., link bundling, unnumbered links, and LSP hierarchy). Since + these concepts were introduced together with GMPLS and since they are + of paramount importance for an operational GMPLS network, they will + be discussed here. + + The organization of the remainder of this document is as follows. We + begin with an introduction of GMPLS. We then present the specific + GMPLS building blocks and explain how they can be combined together + to build an operational GMPLS network. Specific details of the + separate building blocks can be found in the corresponding documents. + +1.1. Acronyms & Abbreviations + + AS Autonomous System + BGP Border Gateway Protocol + CR-LDP Constraint-based Routing LDP + CSPF Constraint-based Shortest Path First + DWDM Dense Wavelength Division Multiplexing + FA Forwarding Adjacency + GMPLS Generalized Multi-Protocol Label Switching + IGP Interior Gateway Protocol + LDP Label Distribution Protocol + LMP Link Management Protocol + + + +Mannie Standards Track [Page 4] + +RFC 3945 GMPLS Architecture October 2004 + + + LSA Link State Advertisement + LSR Label Switching Router + LSP Label Switched Path + MIB Management Information Base + MPLS Multi-Protocol Label Switching + NMS Network Management System + OXC Optical Cross-Connect + PXC Photonic Cross-Connect + RSVP ReSource reserVation Protocol + SDH Synchronous Digital Hierarchy + SONET Synchronous Optical Networks + STM(-N) Synchronous Transport Module (-N) + STS(-N) Synchronous Transport Signal-Level N (SONET) + TDM Time Division Multiplexing + TE Traffic Engineering + +1.2. Multiple Types of Switching and Forwarding Hierarchies + + Generalized MPLS (GMPLS) differs from traditional MPLS in that it + supports multiple types of switching, i.e., the addition of support + for TDM, lambda, and fiber (port) switching. The support for the + additional types of switching has driven GMPLS to extend certain base + functions of traditional MPLS and, in some cases, to add + functionality. These changes and additions impact basic LSP + properties: how labels are requested and communicated, the + unidirectional nature of LSPs, how errors are propagated, and + information provided for synchronizing the ingress and egress LSRs. + + The MPLS architecture [RFC3031] was defined to support the forwarding + of data based on a label. In this architecture, Label Switching + Routers (LSRs) were assumed to have a forwarding plane that is + capable of (a) recognizing either packet or cell boundaries, and (b) + being able to process either packet headers (for LSRs capable of + recognizing packet boundaries) or cell headers (for LSRs capable of + recognizing cell boundaries). + + The original MPLS architecture is here being extended to include LSRs + whose forwarding plane recognizes neither packet, nor cell + boundaries, and therefore, cannot forward data based on the + information carried in either packet or cell headers. Specifically, + such LSRs include devices where the switching decision is based on + time slots, wavelengths, or physical ports. So, the new set of LSRs, + or more precisely interfaces on these LSRs, can be subdivided into + the following classes: + + + + + + + +Mannie Standards Track [Page 5] + +RFC 3945 GMPLS Architecture October 2004 + + + 1. Packet Switch Capable (PSC) interfaces: + + Interfaces that recognize packet boundaries and can forward data + based on the content of the packet header. Examples include + interfaces on routers that forward data based on the content of + the IP header and interfaces on routers that switch data based on + the content of the MPLS "shim" header. + + 2. Layer-2 Switch Capable (L2SC) interfaces: + + Interfaces that recognize frame/cell boundaries and can switch + data based on the content of the frame/cell header. Examples + include interfaces on Ethernet bridges that switch data based on + the content of the MAC header and interfaces on ATM-LSRs that + forward data based on the ATM VPI/VCI. + + 3. Time-Division Multiplex Capable (TDM) interfaces: + + Interfaces that switch data based on the data's time slot in a + repeating cycle. An example of such an interface is that of a + SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add- + Drop Multiplexer (ADM). Other examples include interfaces + providing G.709 TDM capabilities (the "digital wrapper") and PDH + interfaces. + + 4. Lambda Switch Capable (LSC) interfaces: + + Interfaces that switch data based on the wavelength on which the + data is received. An example of such an interface is that of a + Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that + can operate at the level of an individual wavelength. Additional + examples include PXC interfaces that can operate at the level of a + group of wavelengths, i.e., a waveband and G.709 interfaces + providing optical capabilities. + + 5. Fiber-Switch Capable (FSC) interfaces: + + Interfaces that switch data based on a position of the data in the + (real world) physical spaces. An example of such an interface is + that of a PXC or OXC that can operate at the level of a single or + multiple fibers. + + A circuit can be established only between, or through, interfaces of + the same type. Depending on the particular technology being used for + each interface, different circuit names can be used, e.g., SDH + circuit, optical trail, light-path, etc. In the context of GMPLS, + all these circuits are referenced by a common name: Label Switched + Path (LSP). + + + +Mannie Standards Track [Page 6] + +RFC 3945 GMPLS Architecture October 2004 + + + The concept of nested LSP (LSP within LSP), already available in the + traditional MPLS, facilitates building a forwarding hierarchy, i.e., + a hierarchy of LSPs. This hierarchy of LSPs can occur on the same + interface, or between different interfaces. + + For example, a hierarchy can be built if an interface is capable of + multiplexing several LSPs from the same technology (layer), e.g., a + lower order SONET/SDH LSP (e.g., VT2/VC-12) nested in a higher order + SONET/SDH LSP (e.g., STS-3c/VC-4). Several levels of signal (LSP) + nesting are defined in the SONET/SDH multiplexing hierarchy. + + The nesting can also occur between interface types. At the top of + the hierarchy are FSC interfaces, followed by LSC interfaces, + followed by TDM interfaces, followed by L2SC, and followed by PSC + interfaces. This way, an LSP that starts and ends on a PSC interface + can be nested (together with other LSPs) into an LSP that starts and + ends on a L2SC interface. This LSP, in turn, can be nested (together + with other LSPs) into an LSP that starts and ends on a TDM interface. + In turn, this LSP can be nested (together with other LSPs) into an + LSP that starts and ends on a LSC interface, which in turn can be + nested (together with other LSPs) into an LSP that starts and ends on + a FSC interface. + +1.3. Extension of the MPLS Control Plane + + The establishment of LSPs that span only Packet Switch Capable (PSC) + or Layer-2 Switch Capable (L2SC) interfaces is defined for the + original MPLS and/or MPLS-TE control planes. GMPLS extends these + control planes to support each of the five classes of interfaces + (i.e., layers) defined in the previous section. + + Note that the GMPLS control plane supports an overlay model, an + augmented model, and a peer (integrated) model. In the near term, + GMPLS appears to be very suitable for controlling each layer + independently. This elegant approach will facilitate the future + deployment of other models. + + The GMPLS control plane is made of several building blocks as + described in more details in the following sections. These building + blocks are based on well-known signaling and routing protocols that + have been extended and/or modified to support GMPLS. They use IPv4 + and/or IPv6 addresses. Only one new specialized protocol is required + to support the operations of GMPLS, a signaling protocol for link + management [LMP]. + + GMPLS is indeed based on the Traffic Engineering (TE) extensions to + MPLS, a.k.a. MPLS-TE [RFC2702]. This, because most of the + technologies that can be used below the PSC level requires some + + + +Mannie Standards Track [Page 7] + +RFC 3945 GMPLS Architecture October 2004 + + + traffic engineering. The placement of LSPs at these levels needs in + general to consider several constraints (such as framing, bandwidth, + protection capability, etc) and to bypass the legacy Shortest-Path + First (SPF) algorithm. Note, however, that this is not mandatory and + that in some cases SPF routing can be applied. + + In order to facilitate constrained-based SPF routing of LSPs, nodes + that perform LSP establishment need more information about the links + in the network than standard intra-domain routing protocols provide. + These TE attributes are distributed using the transport mechanisms + already available in IGPs (e.g., flooding) and taken into + consideration by the LSP routing algorithm. Optimization of the LSP + routes may also require some external simulations using heuristics + that serve as input for the actual path calculation and LSP + establishment process. + + By definition, a TE link is a representation in the IS-IS/OSPF Link + State advertisements and in the link state database of certain + physical resources, and their properties, between two GMPLS nodes. + TE Links are used by the GMPLS control plane (routing and signaling) + for establishing LSPs. + + Extensions to traditional routing protocols and algorithms are needed + to uniformly encode and carry TE link information, and explicit + routes (e.g., source routes) are required in the signaling. In + addition, the signaling must now be capable of transporting the + required circuit (LSP) parameters such as the bandwidth, the type of + signal, the desired protection and/or restoration, the position in a + particular multiplex, etc. Most of these extensions have already + been defined for PSC and L2SC traffic engineering with MPLS. GMPLS + primarily defines additional extensions for TDM, LSC, and FSC traffic + engineering. A very few elements are technology specific. + + Thus, GMPLS extends the two signaling protocols defined for MPLS-TE + signaling, i.e., RSVP-TE [RFC3209] and CR-LDP [RFC3212]. However, + GMPLS does not specify which one of these two signaling protocols + must be used. It is the role of manufacturers and operators to + evaluate the two possible solutions for their own interest. + + Since GMPLS signaling is based on RSVP-TE and CR-LDP, it mandates a + downstream-on-demand label allocation and distribution, with ingress + initiated ordered control. Liberal label retention is normally used, + but conservative label retention mode could also be used. + + + + + + + + +Mannie Standards Track [Page 8] + +RFC 3945 GMPLS Architecture October 2004 + + + Furthermore, there is no restriction on the label allocation + strategy, it can be request/signaling driven (obvious for circuit + switching technologies), traffic/data driven, or even topology + driven. There is also no restriction on the route selection; + explicit routing is normally used (strict or loose) but hop-by-hop + routing could be used as well. + + GMPLS also extends two traditional intra-domain link-state routing + protocols already extended for TE purposes, i.e., OSPF-TE [OSPF-TE] + and IS-IS-TE [ISIS-TE]. However, if explicit (source) routing is + used, the routing algorithms used by these protocols no longer need + to be standardized. Extensions for inter-domain routing (e.g., BGP) + are for further study. + + The use of technologies like DWDM (Dense Wavelength Division + Multiplexing) implies that we can now have a very large number of + parallel links between two directly adjacent nodes (hundreds of + wavelengths, or even thousands of wavelengths if multiple fibers are + used). Such a large number of links was not originally considered + for an IP or MPLS control plane, although it could be done. Some + slight adaptations of that control plane are thus required if we want + to better reuse it in the GMPLS context. + + For instance, the traditional IP routing model assumes the + establishment of a routing adjacency over each link connecting two + adjacent nodes. Having such a large number of adjacencies does not + scale well. Each node needs to maintain each of its adjacencies one + by one, and link state routing information must be flooded throughout + the network. + + To solve this issue the concept of link bundling was introduced. + Moreover, the manual configuration and control of these links, even + if they are unnumbered, becomes impractical. The Link Management + Protocol (LMP) was specified to solve these issues. + + LMP runs between data plane adjacent nodes and is used to manage TE + links. Specifically, LMP provides mechanisms to maintain control + channel connectivity (IP Control Channel Maintenance), verify the + physical connectivity of the data-bearing links (Link Verification), + correlate the link property information (Link Property Correlation), + and manage link failures (Fault Localization and Fault Notification). + A unique feature of LMP is that it is able to localize faults in both + opaque and transparent networks (i.e., independent of the encoding + scheme and bit rate used for the data). + + LMP is defined in the context of GMPLS, but is specified + independently of the GMPLS signaling specification since it is a + local protocol running between data-plane adjacent nodes. + + + +Mannie Standards Track [Page 9] + +RFC 3945 GMPLS Architecture October 2004 + + + Consequently, LMP can be used in other contexts with non-GMPLS + signaling protocols. + + MPLS signaling and routing protocols require at least one bi- + directional control channel to communicate even if two adjacent nodes + are connected by unidirectional links. Several control channels can + be used. LMP can be used to establish, maintain and manage these + control channels. + + GMPLS does not specify how these control channels must be + implemented, but GMPLS requires IP to transport the signaling and + routing protocols over them. Control channels can be either in-band + or out-of-band, and several solutions can be used to carry IP. Note + also that one type of LMP message (the Test message) is used in-band + in the data plane and may not be transported over IP, but this is a + particular case, needed to verify connectivity in the data plane. + +1.4. GMPLS Key Extensions to MPLS-TE + + Some key extensions brought by GMPLS to MPLS-TE are highlighted in + the following. Some of them are key advantages of GMPLS to control + TDM, LSC and FSC layers. + + - In MPLS-TE, links traversed by an LSP can include an intermix of + links with heterogeneous label encoding (e.g., links between + routers, links between routers and ATM-LSRs, and links between + ATM-LSRs. GMPLS extends this by including links where the label is + encoded as a time slot, or a wavelength, or a position in the + (real world) physical space. + + - In MPLS-TE, an LSP that carries IP has to start and end on a + router. GMPLS extends this by requiring an LSP to start and end + on similar type of interfaces. + + - The type of a payload that can be carried in GMPLS by an LSP is + extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb + Ethernet, etc. + + - The use of Forwarding Adjacencies (FA) provides a mechanism that + can improve bandwidth utilization, when bandwidth allocation can + be performed only in discrete units. It offers also a mechanism + to aggregate forwarding state, thus allowing the number of + required labels to be reduced. + + + + + + + + +Mannie Standards Track [Page 10] + +RFC 3945 GMPLS Architecture October 2004 + + + - GMPLS allows suggesting a label by an upstream node to reduce the + setup latency. This suggestion may be overridden by a downstream + node but in some cases, at the cost of higher LSP setup time. + + - GMPLS extends on the notion of restricting the range of labels + that may be selected by a downstream node. In GMPLS, an upstream + node may restrict the labels for an LSP along either a single hop + or the entire LSP path. This feature is useful in photonic + networks where wavelength conversion may not be available. + + - While traditional TE-based (and even LDP-based) LSPs are + unidirectional, GMPLS supports the establishment of bi-directional + LSPs. + + - GMPLS supports the termination of an LSP on a specific egress + port, i.e., the port selection at the destination side. + + - GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid + failure notification. + + Note also some other key differences between MPLS-TE and GMPLS: + + - For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP + can be performed only in discrete units. + + - It is expected to have (much) fewer labels on TDM, LSC or FSC + links than on PSC or L2SC links, because the former are physical + labels instead of logical labels. + +2. Routing and Addressing Model + + GMPLS is based on the IP routing and addressing models. This assumes + that IPv4 and/or IPv6 addresses are used to identify interfaces but + also that traditional (distributed) IP routing protocols are reused. + Indeed, the discovery of the topology and the resource state of all + links in a routing domain is achieved via these routing protocols. + + Since control and data planes are de-coupled in GMPLS, control-plane + neighbors (i.e., IGP-learnt neighbors) may not be data-plane + neighbors. Hence, mechanisms like LMP are needed to associate TE + links with neighboring nodes. + + IP addresses are not used only to identify interfaces of IP hosts and + routers, but more generally to identify any PSC and non-PSC + interfaces. Similarly, IP routing protocols are used to find routes + for IP datagrams with a SPF algorithm; they are also used to find + routes for non-PSC circuits by using a CSPF algorithm. + + + + +Mannie Standards Track [Page 11] + +RFC 3945 GMPLS Architecture October 2004 + + + However, some additional mechanisms are needed to increase the + scalability of these models and to deal with specific traffic + engineering requirements of non-PSC layers. These mechanisms will be + introduced in the following. + + Re-using existing IP routing protocols allows for non-PSC layers + taking advantage of all the valuable developments that took place + since years for IP routing, in particular, in the context of intra- + domain routing (link-state routing) and inter-domain routing (policy + routing). + + In an overlay model, each particular non-PSC layer can be seen as a + set of Autonomous Systems (ASs) interconnected in an arbitrary way. + Similarly to the traditional IP routing, each AS is managed by a + single administrative authority. For instance, an AS can be an + SONET/SDH network operated by a given carrier. The set of + interconnected ASs can be viewed as SONET/SDH internetworks. + + Exchange of routing information between ASs can be done via an + inter-domain routing protocol like BGP-4. There is obviously a huge + value of re-using well-known policy routing facilities provided by + BGP in a non-PSC context. Extensions for BGP traffic engineering + (BGP-TE) in the context of non-PSC layers are left for further study. + + Each AS can be sub-divided in different routing domains, and each can + run a different intra-domain routing protocol. In turn, each + routing-domain can be divided in areas. + + A routing domain is made of GMPLS enabled nodes (i.e., a network + device including a GMPLS entity). These nodes can be either edge + nodes (i.e., hosts, ingress LSRs or egress LSRs), or internal LSRs. + An example of non-PSC host is an SONET/SDH Terminal Multiplexer (TM). + Another example is an SONET/SDH interface card within an IP router or + ATM switch. + + Note that traffic engineering in the intra-domain requires the use of + link-state routing protocols like OSPF or IS-IS. + + GMPLS defines extensions to these protocols. These extensions are + needed to disseminate specific TDM, LSC and FSC static and dynamic + characteristics related to nodes and links. The current focus is on + + + + + + + + + + +Mannie Standards Track [Page 12] + +RFC 3945 GMPLS Architecture October 2004 + + + intra-area traffic engineering. However, inter-area traffic + engineering is also under investigation. + +2.1. Addressing of PSC and non-PSC Layers + + The fact that IPv4 and/or IPv6 addresses are used does not imply at + all that they should be allocated in the same addressing space than + public IPv4 and/or IPv6 addresses used for the Internet. Private IP + addresses can be used if they do not require to be exchanged with any + other operator; public IP addresses are otherwise required. Of + course, if an integrated model is used, two layers could share the + same addressing space. Finally, TE links may be "unnumbered" i.e., + not have any IP addresses, in case IP addresses are not available, or + the overhead of managing them is considered too high. + + Note that there is a benefit of using public IPv4 and/or IPv6 + Internet addresses for non-PSC layers if an integrated model with the + IP layer is foreseen. + + If we consider the scalability enhancements proposed in the next + section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing spaces + are both more than sufficient to accommodate any non-PSC layer. We + can reasonably expect to have much less non-PSC devices (e.g., + SONET/SDH nodes) than we have today IP hosts and routers. + +2.2. GMPLS Scalability Enhancements + + TDM, LSC and FSC layers introduce new constraints on the IP + addressing and routing models since several hundreds of parallel + physical links (e.g., wavelengths) can now connect two nodes. Most + of the carriers already have today several tens of wavelengths per + fiber between two nodes. New generation of DWDM systems will allow + several hundreds of wavelengths per fiber. + + It becomes rather impractical to associate an IP address with each + end of each physical link, to represent each link as a separate + routing adjacency, and to advertise and to maintain link states for + each of these links. For that purpose, GMPLS enhances the MPLS + routing and addressing models to increase their scalability. + + Two optional mechanisms can be used to increase the scalability of + the addressing and the routing: unnumbered links and link bundling. + These two mechanisms can also be combined. They require extensions + to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE) + protocols. + + + + + + +Mannie Standards Track [Page 13] + +RFC 3945 GMPLS Architecture October 2004 + + +2.3. TE Extensions to IP Routing Protocols + + Traditionally, a TE link is advertised as an adjunct to a "regular" + OSPF or IS-IS link, i.e., an adjacency is brought up on the link. + When the link is up, both the regular IGP properties of the link + (basically, the SPF metric) and the TE properties of the link are + then advertised. + + However, GMPLS challenges this notion in three ways: + + - First, links that are non-PSC may yet have TE properties; however, + an OSPF adjacency could not be brought up directly on such links. + + - Second, an LSP can be advertised as a point-to-point TE link in + the routing protocol, i.e., as a Forwarding Adjacency (FA); thus, + an advertised TE link need no longer be between two OSPF direct + neighbors. Forwarding Adjacencies (FA) are further described in + Section 8. + + - Third, a number of links may be advertised as a single TE link + (e.g., for improved scalability), so again, there is no longer a + one-to-one association of a regular adjacency and a TE link. + + Thus, we have a more general notion of a TE link. A TE link is a + logical link that has TE properties. Some of these properties may be + configured on the advertising LSR, others may be obtained from other + LSRs by means of some protocol, and yet others may be deduced from + the component(s) of the TE link. + + An important TE property of a TE link is related to the bandwidth + accounting for that link. GMPLS will define different accounting + rules for different non-PSC layers. Generic bandwidth attributes are + however defined by the TE routing extensions and by GMPLS, such as + the unreserved bandwidth, the maximum reservable bandwidth and the + maximum LSP bandwidth. + + It is expected in a dynamic environment to have frequent changes of + bandwidth accounting information. A flexible policy for triggering + link state updates based on bandwidth thresholds and link-dampening + mechanism can be implemented. + + TE properties associated with a link should also capture protection + and restoration related characteristics. For instance, shared + protection can be elegantly combined with bundling. Protection and + restoration are mainly generic mechanisms also applicable to MPLS. It + is expected that they will first be developed for MPLS and later on + generalized to GMPLS. + + + + +Mannie Standards Track [Page 14] + +RFC 3945 GMPLS Architecture October 2004 + + + A TE link between a pair of LSRs does not imply the existence of an + IGP adjacency between these LSRs. A TE link must also have some + means by which the advertising LSR can know of its liveness (e.g., by + using LMP hellos). When an LSR knows that a TE link is up, and can + determine the TE link's TE properties, the LSR may then advertise + that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE + objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF + or IS-IS adjacencies are established "control channels". + +3. Unnumbered Links + + Unnumbered links (or interfaces) are links (or interfaces) that do + not have IP addresses. Using such links involves two capabilities: + the ability to specify unnumbered links in MPLS TE signaling, and the + ability to carry (TE) information about unnumbered links in IGP TE + extensions of IS-IS-TE and OSPF-TE. + + A. The ability to specify unnumbered links in MPLS TE signaling + requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480]. + The MPLS-TE signaling does not provide support for unnumbered + links, because it does not provide a way to indicate an unnumbered + link in its Explicit Route Object/TLV and in its Record Route + Object (there is no such TLV for CR-LDP). GMPLS defines simple + extensions to indicate an unnumbered link in these two + Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub- + TLV. + + Since unnumbered links are not identified by an IP address, then + for the purpose of MPLS TE each end need some other identifier, + local to the LSR to which the link belongs. LSRs at the two end- + points of an unnumbered link exchange with each other the + identifiers they assign to the link. Exchanging the identifiers + may be accomplished by configuration, by means of a protocol such + as LMP ([LMP]), by means of RSVP-TE/CR-LDP (especially in the case + where a link is a Forwarding Adjacency, see below), or by means of + IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]). + + Consider an (unnumbered) link between LSRs A and B. LSR A chooses + an identifier for that link. So does LSR B. From A's perspective + we refer to the identifier that A assigned to the link as the + "link local identifier" (or just "local identifier"), and to the + identifier that B assigned to the link as the "link remote + identifier" (or just "remote identifier"). Likewise, from B's + perspective the identifier that B assigned to the link is the + local identifier, and the identifier that A assigned to the link + is the remote identifier. + + + + + +Mannie Standards Track [Page 15] + +RFC 3945 GMPLS Architecture October 2004 + + + The new Unnumbered Interface ID sub-object/sub-TLV for the ER + Object/TLV contains the Router ID of the LSR at the upstream end + of the unnumbered link and the link local identifier with respect + to that upstream LSR. + + The new Unnumbered Interface ID sub-object for the RR Object + contains the link local identifier with respect to the LSR that + adds it in the RR Object. + + B. The ability to carry (TE) information about unnumbered links in + IGP TE extensions requires new sub-TLVs for the extended IS + reachability TLV defined in IS-IS-TE and for the TE LSA (which is + an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub- + TLV and a Link Remote Identifier sub-TLV are defined. + +3.1. Unnumbered Forwarding Adjacencies + + If an LSR that originates an LSP advertises this LSP as an unnumbered + FA in IS-IS or OSPF, or the LSR uses this FA as an unnumbered + component link of a bundled link, the LSR must allocate an Interface + ID to that FA. If the LSP is bi-directional, the tail end does the + same and allocates an Interface ID to the reverse FA. + + Signaling has been enhanced to carry the Interface ID of a FA in the + new LSP Tunnel Interface ID object/TLV. This object/TLV contains the + Router ID (of the LSR that generates it) and the Interface ID. It is + called the Forward Interface ID when it appears in a Path/REQUEST + message, and it is called the Reverse Interface ID when it appears in + the Resv/MAPPING message. + +4. Link Bundling + + The concept of link bundling is essential in certain networks + employing the GMPLS control plane as is defined in [BUNDLE]. A + typical example is an optical meshed network where adjacent optical + cross-connects (LSRs) are connected by several hundreds of parallel + wavelengths. In this network, consider the application of link state + routing protocols, like OSPF or IS-IS, with suitable extensions for + resource discovery and dynamic route computation. Each wavelength + must be advertised separately to be used, except if link bundling is + used. + + When a pair of LSRs is connected by multiple links, it is possible to + advertise several (or all) of these links as a single link into OSPF + and/or IS-IS. This process is called link bundling, or just + bundling. The resulting logical link is called a bundled link as its + physical links are called component links (and are identified by + interface indexes). + + + +Mannie Standards Track [Page 16] + +RFC 3945 GMPLS Architecture October 2004 + + + The result is that a combination of three identifiers ((bundled) link + identifier, component link identifier, label) is sufficient to + unambiguously identify the appropriate resources used by an LSP. + + The purpose of link bundling is to improve routing scalability by + reducing the amount of information that has to be handled by OSPF + and/or IS-IS. This reduction is accomplished by performing + information aggregation/abstraction. As with any other information + aggregation/abstraction, this results in losing some of the + information. To limit the amount of losses one need to restrict the + type of the information that can be aggregated/abstracted. + +4.1. Restrictions on Bundling + + The following restrictions are required for bundling links. All + component links in a bundle must begin and end on the same pair of + LSRs; and share some common characteristics or properties defined in + [OSPF-TE] and [ISIS-TE], i.e., they must have the same: + + - Link Type (i.e., point-to-point or multi-access), + - TE Metric (i.e., an administrative cost), + - Set of Resource Classes at each end of the links (i.e., colors). + + Note that a FA may also be a component link. In fact, a bundle can + consist of a mix of point-to-point links and FAs, but all sharing + some common properties. + +4.2. Routing Considerations for Bundling + + A bundled link is just another kind of TE link such as those defined + by [GMPLS-ROUTING]. The liveness of the bundled link is determined + by the liveness of each its component links. A bundled link is alive + when at least one of its component links is alive. The liveness of a + component link can be determined by any of several means: IS-IS or + OSPF hellos over the component link, or RSVP Hello (hop local), or + LMP hellos (link local), or from layer 1 or layer 2 indications. + + Note that (according to the RSVP-TE specification [RFC3209]) the RSVP + Hello mechanism is intended to be used when notification of link + layer failures is not available and unnumbered links are not used, or + when the failure detection mechanisms provided by the link layer are + not sufficient for timely node failure detection. + + Once a bundled link is determined to be alive, it can be advertised + as a TE link and the TE information can be flooded. If IS-IS/OSPF + hellos are run over the component links, IS-IS/OSPF flooding can be + restricted to just one of the component links. + + + + +Mannie Standards Track [Page 17] + +RFC 3945 GMPLS Architecture October 2004 + + + Note that advertising a (bundled) TE link between a pair of LSRs does + not imply that there is an IGP adjacency between these LSRs that is + associated with just that link. In fact, in certain cases a TE link + between a pair of LSRs could be advertised even if there is no IGP + adjacency at all between the LSR (e.g., when the TE link is an FA). + + Forming a bundled link consist in aggregating the identical TE + parameters of each individual component link to produce aggregated TE + parameters. A TE link as defined by [GMPLS-ROUTING] has many + parameters; adequate aggregation rules must be defined for each one. + + Some parameters can be sums of component characteristics such as the + unreserved bandwidth and the maximum reservable bandwidth. Bandwidth + information is an important part of a bundle advertisement and it + must be clearly defined since an abstraction is done. + + A GMPLS node with bundled links must apply admission control on a + per-component link basis. + +4.3. Signaling Considerations + + Typically, an LSP's explicit route (e.g., contained in an explicit + route Object/TLV) will choose the bundled link to be used for the + LSP, but not the component link(s). This because information about + the bundled link is flooded but information about the component links + is not. + + The choice of the component link to use is always made by an upstream + node. If the LSP is bi-directional, the upstream node chooses a + component link in each direction. + + Three mechanisms for indicating this choice to the downstream node + are possible. + +4.3.1. Mechanism 1: Implicit Indication + + This mechanism requires that each component link has a dedicated + signaling channel (e.g., the link is a Sonet/SDH link using the DCC + for in-band signaling). The upstream node tells the receiver which + component link to use by sending the message over the chosen + component link's dedicated signaling channel. Note that this + signaling channel can be in-band or out-of-band. In this last case, + the association between the signaling channel and that component link + need to be explicitly configured. + + + + + + + +Mannie Standards Track [Page 18] + +RFC 3945 GMPLS Architecture October 2004 + + +4.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID + + This mechanism requires that the component link has a unique remote + IP address. The upstream node indicates the choice of the component + link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying + either an IPv4 or an IPv6 address in the Path/Label Request message + (see [RFC3473]/[RFC3472], respectively). For a bi-directional LSP, a + component link is provided for each direction by the upstream node. + + This mechanism does not require each component link to have its own + control channel. In fact, it does not even require the whole + (bundled) link to have its own control channel. + +4.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID + + With this mechanism, each component link that is unnumbered is + assigned a unique Interface Identifier (32 bits value). The upstream + node indicates the choice of the component link by including a new + IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message + (see [RFC3473]/[RFC3472], respectively). + + This object/TLV carries the component interface ID in the downstream + direction for a unidirectional LSP, and in addition, the component + interface ID in the upstream direction for a bi-directional LSP. + + The two LSRs at each end of the bundled link exchange these + identifiers. Exchanging the identifiers may be accomplished by + configuration, by means of a protocol such as LMP (preferred + solution), by means of RSVP-TE/CR-LDP (especially in the case where a + component link is a Forwarding Adjacency), or by means of IS-IS or + OSPF extensions. + + This mechanism does not require each component link to have its own + control channel. In fact, it does not even require the whole + (bundled) link to have its own control channel. + +4.4. Unnumbered Bundled Link + + A bundled link may itself be numbered or unnumbered independent of + whether the component links are numbered or not. This affects how + the bundled link is advertised in IS-IS/OSPF and the format of LSP + EROs that traverse the bundled link. Furthermore, unnumbered + Interface Identifiers for all unnumbered outgoing links of a given + LSR (whether component links, Forwarding Adjacencies or bundled + links) must be unique in the context of that LSR. + + + + + + +Mannie Standards Track [Page 19] + +RFC 3945 GMPLS Architecture October 2004 + + +4.5. Forming Bundled Links + + The generic rule for bundling component links is to place those links + that are correlated in some manner in the same bundle. If links may + be correlated based on multiple properties then the bundling may be + applied sequentially based on these properties. For instance, links + may be first grouped based on the first property. Each of these + groups may be then divided into smaller groups based on the second + property and so on. The main principle followed in this process is + that the properties of the resulting bundles should be concisely + summarizable. Link bundling may be done automatically or by + configuration. Automatic link bundling can apply bundling rules + sequentially to produce bundles. + + For instance, the first property on which component links may be + correlated could be the Interface Switching Capability + [GMPLS-ROUTING], the second property could be the Encoding + [GMPLS-ROUTING], the third property could be the Administrative + Weight (cost), the fourth property could be the Resource Classes and + finally links may be correlated based on other metrics such as SRLG + (Shared Risk Link Groups). + + When routing an alternate path for protection purposes, the general + principle followed is that the alternate path is not routed over any + link belonging to an SRLG that belongs to some link of the primary + path. Thus, the rule to be followed is to group links belonging to + exactly the same set of SRLGs. + + This type of sequential sub-division may result in a number of + bundles between two adjacent nodes. In practice, however, the link + properties may not be very heterogeneous among component links + between two adjacent nodes. Thus, the number of bundles in practice + may not be large. + +5. Relationship with the UNI + + The interface between an edge GMPLS node and a GMPLS LSR on the + network side may be referred to as a User to Network Interface (UNI), + while the interface between two-network side LSRs may be referred to + as a Network to Network Interface (NNI). + + GMPLS does not specify separately a UNI and an NNI. Edge nodes are + connected to LSRs on the network side, and these LSRs are in turn + connected between them. Of course, the behavior of an edge node is + not exactly the same as the behavior of an LSR on the network side. + Note also, that an edge node may run a routing protocol, however it + is expected that in most of the cases it will not (see also section + 5.2 and the section about signaling with an explicit route). + + + +Mannie Standards Track [Page 20] + +RFC 3945 GMPLS Architecture October 2004 + + + Conceptually, a difference between UNI and NNI make sense either if + both interface uses completely different protocols, or if they use + the same protocols but with some outstanding differences. In the + first case, separate protocols are often defined successively, with + more or less success. + + The GMPLS approach consisted in building a consistent model from day + one, considering both the UNI and NNI interfaces at the same time + [GMPLS-OVERLAY]. For that purpose, a very few specific UNI + particularities have been ignored in a first time. GMPLS has been + enhanced to support such particularities at the UNI by some other + standardization bodies (see hereafter). + +5.1. Relationship with the OIF UNI + + This section is only given for reference to the OIF work related to + GMPLS. The current OIF UNI specification [OIF-UNI] defines an + interface between a client SONET/SDH equipment and an SONET/SDH + network, each belonging to a distinct administrative authority. It + is designed for an overlay model. The OIF UNI defines additional + mechanisms on the top of GMPLS for the UNI. + + For instance, the OIF service discovery procedure is a precursor to + obtaining UNI services. Service discovery allows a client to + determine the static parameters of the interconnection with the + network, including the UNI signaling protocol, the type of + concatenation, the transparency level as well as the type of + diversity (node, link, SRLG) supported by the network. + + Since the current OIF UNI interface does not cover photonic networks, + G.709 Digital Wrapper, etc, it is from that perspective a subset of + the GMPLS Architecture at the UNI. + +5.2. Reachability across the UNI + + This section discusses the selection of an explicit route by an edge + node. The selection of the first LSR by an edge node connected to + multiple LSRs is part of that problem. + + An edge node (host or LSR) can participate more or less deeply in the + GMPLS routing. Four different routing models can be supported at the + UNI: configuration based, partial peering, silent listening and full + peering. + + - Configuration based: this routing model requires the manual or + automatic configuration of an edge node with a list of neighbor + LSRs sorted by preference order. Automatic configuration can be + achieved using DHCP for instance. No routing information is + + + +Mannie Standards Track [Page 21] + +RFC 3945 GMPLS Architecture October 2004 + + + exchanged at the UNI, except maybe the ordered list of LSRs. The + only routing information used by the edge node is that list. The + edge node sends by default an LSP request to the preferred LSR. + ICMP redirects could be send by this LSR to redirect some LSP + requests to another LSR connected to the edge node. GMPLS does + not preclude that model. + + - Partial peering: limited routing information (mainly reachability) + can be exchanged across the UNI using some extensions in the + signaling plane. The reachability information exchanged at the + UNI may be used to initiate edge node specific routing decision + over the network. GMPLS does not have any capability to support + this model today. + + - Silent listening: the edge node can silently listen to routing + protocols and take routing decisions based on the information + obtained. An edge node receives the full routing information, + including traffic engineering extensions. One LSR should forward + transparently all routing PDUs to the edge node. An edge node can + now compute a complete explicit route taking into consideration + all the end-to-end routing information. GMPLS does not preclude + this model. + + - Full peering: in addition to silent listening, the edge node + participates within the routing, establish adjacencies with its + neighbors and advertises LSAs. This is useful only if there are + benefits for edge nodes to advertise themselves traffic + engineering information. GMPLS does not preclude this model. + +6. Link Management + + In the context of GMPLS, a pair of nodes (e.g., a photonic switch) + may be connected by tens of fibers, and each fiber may be used to + transmit hundreds of wavelengths if DWDM is used. Multiple fibers + and/or multiple wavelengths may also be combined into one or more + bundled links for routing purposes. Furthermore, to enable + communication between nodes for routing, signaling, and link + management, control channels must be established between a node pair. + + Link management is a collection of useful procedures between adjacent + nodes that provide local services such as control channel management, + link connectivity verification, link property correlation, and fault + management. The Link Management Protocol (LMP) [LMP] has been + defined to fulfill these operations. LMP has been initiated in the + context of GMPLS but is a generic toolbox that can be also used in + other contexts. + + + + + +Mannie Standards Track [Page 22] + +RFC 3945 GMPLS Architecture October 2004 + + + In GMPLS, the control channels between two adjacent nodes are no + longer required to use the same physical medium as the data links + between those nodes. Moreover, the control channels that are used to + exchange the GMPLS control-plane information exist independently of + the links they manage. Hence, LMP was designed to manage the data + links, independently of the termination capabilities of those data + links. + + Control channel management and link property correlation procedures + are mandatory per LMP. Link connectivity verification and fault + management procedures are optional. + +6.1. Control Channel and Control Channel Management + + LMP control channel management is used to establish and maintain + control channels between nodes. Control channels exist independently + of TE links, and can be used to exchange MPLS control-plane + information such as signaling, routing, and link management + information. + + An "LMP adjacency" is formed between two nodes that support the same + LMP capabilities. Multiple control channels may be active + simultaneously for each adjacency. A control channel can be either + explicitly configured or automatically selected, however, LMP + currently assume that control channels are explicitly configured + while the configuration of the control channel capabilities can be + dynamically negotiated. + + For the purposes of LMP, the exact implementation of the control + channel is left unspecified. The control channel(s) between two + adjacent nodes is no longer required to use the same physical medium + as the data-bearing links between those nodes. For example, a + control channel could use a separate wavelength or fiber, an Ethernet + link, or an IP tunnel through a separate management network. + + A consequence of allowing the control channel(s) between two nodes to + be physically diverse from the associated data-bearing links is that + the health of a control channel does not necessarily correlate to the + health of the data-bearing links, and vice-versa. Therefore, new + mechanisms have been developed in LMP to manage links, both in terms + of link provisioning and fault isolation. + + LMP does not specify the signaling transport mechanism used in the + control channel, however it states that messages transported over a + control channel must be IP encoded. Furthermore, since the messages + are IP encoded, the link level encoding is not part of LMP. A 32-bit + non-zero integer Control Channel Identifier (CCId) is assigned to + each direction of a control channel. + + + +Mannie Standards Track [Page 23] + +RFC 3945 GMPLS Architecture October 2004 + + + Each control channel individually negotiates its control channel + parameters and maintains connectivity using a fast Hello protocol. + The latter is required if lower-level mechanisms are not available to + detect link failures. + + The Hello protocol of LMP is intended to be a lightweight keep-alive + mechanism that will react to control channel failures rapidly so that + IGP Hellos are not lost and the associated link-state adjacencies are + not removed uselessly. + + The Hello protocol consists of two phases: a negotiation phase and a + keep-alive phase. The negotiation phase allows negotiation of some + basic Hello protocol parameters, like the Hello frequency. The + keep-alive phase consists of a fast lightweight bi-directional Hello + message exchange. + + If a group of control channels share a common node pair and support + the same LMP capabilities, then LMP control channel messages (except + Configuration messages, and Hello's) may be transmitted over any of + the active control channels without coordination between the local + and remote nodes. + + For LMP, it is essential that at least one control channel is always + available. In case of control channel failure, it may be possible to + use an alternate active control channel without coordination. + +6.2. Link Property Correlation + + As part of LMP, a link property correlation exchange is defined. The + exchange is used to aggregate multiple data-bearing links (i.e., + component links) into a bundled link and exchange, correlate, or + change TE link parameters. The link property correlation exchange + may be done at any time a link is up and not in the Verification + process (see next section). + + It allows, for instance, the addition of component links to a link + bundle, change of a link's minimum/maximum reservable bandwidth, + change of port identifiers, or change of component identifiers in a + bundle. This mechanism is supported by an exchange of link summary + messages. + +6.3. Link Connectivity Verification + + Link connectivity verification is an optional procedure that may be + used to verify the physical connectivity of data-bearing links as + well as to exchange the link identifiers that are used in the GMPLS + signaling. + + + + +Mannie Standards Track [Page 24] + +RFC 3945 GMPLS Architecture October 2004 + + + This procedure should be performed initially when a data-bearing link + is first established, and subsequently, on a periodic basis for all + unallocated (free) data-bearing links. + + The verification procedure consists of sending Test messages in-band + over the data-bearing links. This requires that the unallocated + links must be opaque; however, multiple degrees of opaqueness (e.g., + examining overhead bytes, terminating the payload, etc.), and hence + different mechanisms to transport the Test messages, are specified. + Note that the Test message is the only LMP message that is + transmitted over the data-bearing link, and that Hello messages + continue to be exchanged over the control channel during the link + verification process. Data-bearing links are tested in the transmit + direction as they are unidirectional. As such, it is possible for + LMP neighboring nodes to exchange the Test messages simultaneously in + both directions. + + To initiate the link verification procedure, a node must first notify + the adjacent node that it will begin sending Test messages over a + particular data-bearing link, or over the component links of a + particular bundled link. The node must also indicate the number of + data-bearing links that are to be verified; the interval at which the + test messages will be sent; the encoding scheme, the transport + mechanisms that are supported, the data rate for Test messages; and, + in the case where the data-bearing links correspond to fibers, the + wavelength over which the Test messages will be transmitted. + Furthermore, the local and remote bundled link identifiers are + transmitted at this time to perform the component link association + with the bundled link identifiers. + +6.4. Fault Management + + Fault management is an important requirement from the operational + point of view. Fault management includes usually: fault detection, + fault localization and fault notification. When a failure occurs and + is detected (fault detection), an operator needs to know exactly + where it happened (fault localization) and a source node may need to + be notified in order to take some actions (fault notification). + + Note that fault localization can also be used to support some + specific (local) protection/restoration mechanisms. + + In new technologies such as transparent photonic switching currently + no method is defined to locate a fault, and the mechanism by which + the fault information is propagated must be sent "out of band" (via + the control plane). + + + + + +Mannie Standards Track [Page 25] + +RFC 3945 GMPLS Architecture October 2004 + + + LMP provides a fault localization procedure that can be used to + rapidly localize link failures, by notifying a fault up to the node + upstream of that fault (i.e., through a fault notification + procedure). + + A downstream LMP neighbor that detects data link failures will send + an LMP message to its upstream neighbor notifying it of the failure. + When an upstream node receives a failure notification, it can + correlate the failure with the corresponding input ports to determine + if the failure is between the two nodes. Once the failure has been + localized, the signaling protocols can be used to initiate link or + path protection/restoration procedures. + +6.5. LMP for DWDM Optical Line Systems (OLSs) + + In an all-optical environment, LMP focuses on peer communications + (e.g., OXC-to-OXC). A great deal of information about a link between + two OXCs is known by the OLS (Optical Line System or WDM Terminal + multiplexer). Exposing this information to the control plane can + improve network usability by further reducing required manual + configuration, and by greatly enhancing fault detection and recovery. + + LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC + and an OLS. These extensions are intended to satisfy the Optical + Link Interface Requirements described in [OLI-REQ]. + + Fault detection is particularly an issue when the network is using + all-optical photonic switches (PXC). Once a connection is + established, PXCs have only limited visibility into the health of the + connection. Although the PXC is all-optical, long-haul OLSs + typically terminate channels electrically and regenerate them + optically. This provides an opportunity to monitor the health of a + channel between PXCs. LMP-WDM can then be used by the OLS to provide + this information to the PXC. + + In addition to the link information known to the OLS that is + exchanged through LMP-WDM, some information known to the OXC may also + be exchanged with the OLS through LMP-WDM. This information is + useful for alarm management and link monitoring (e.g., trace + monitoring). Alarm management is important because the + administrative state of a connection, known to the OXC (e.g., this + information may be learned through the Admin Status object of GMPLS + signaling [RFC3471]), can be used to suppress spurious alarms. For + example, the OXC may know that a connection is "up", "down", in a + "testing" mode, or being deleted ("deletion-in-progress"). The OXC + can use this information to inhibit alarm reporting from the OLS when + a connection is "down", "testing", or being deleted. + + + + +Mannie Standards Track [Page 26] + +RFC 3945 GMPLS Architecture October 2004 + + + It is important to note that an OXC may peer with one or more OLSs + and an OLS may peer with one or more OXCs. Although there are many + similarities between an OXC-OXC LMP session and an OXC-OLS LMP + session, particularly for control management and link verification, + there are some differences as well. These differences can primarily + be attributed to the nature of an OXC-OLS link, and the purpose of + OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the + basis for GMPLS signaling and routing at the optical layer. The + information exchanged over LMP-WDM sessions is used to augment + knowledge about the links between OXCs. + + In order for the information exchanged over the OXC-OLS LMP sessions + to be used by the OXC-OXC session, the information must be + coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP + sessions are run independently and must be maintained separately. One + critical requirement when running an OXC-OLS LMP session is the + ability of the OLS to make a data link transparent when not doing the + verification procedure. This is because the same data link may be + verified between OXC-OLS and between OXC-OXC. The verification + procedure of LMP is used to coordinate the Test procedure (and hence + the transparency/opaqueness of the data links). To maintain + independence between the sessions, it must be possible for the LMP + sessions to come up in any order. In particular, it must be possible + for an OXC-OXC LMP session to come up without an OXC-OLS LMP session + being brought up, and vice-versa. + +7. Generalized Signaling + + The GMPLS signaling extends certain base functions of the RSVP-TE and + CR-LDP signaling and, in some cases, adds functionality. These + changes and additions impact basic LSP properties: how labels are + requested and communicated, the unidirectional nature of LSPs, how + errors are propagated, and information provided for synchronizing the + ingress and egress. + + The core GMPLS signaling specification is available in three parts: + + 1. A signaling functional description [RFC3471]. + 2. RSVP-TE extensions [RFC3473]. + 3. CR-LDP extensions [RFC3472]. + + In addition, independent parts are available per technology: + + 1. GMPLS extensions for SONET and SDH control [RFC3946]. + 2. GMPLS extensions for G.709 control [GMPLS-G709]. + + + + + + +Mannie Standards Track [Page 27] + +RFC 3945 GMPLS Architecture October 2004 + + + The following MPLS profile expressed in terms of MPLS features + [RFC3031] applies to GMPLS: + + - Downstream-on-demand label allocation and distribution. + + - Ingress initiated ordered control. + + - Liberal (typical), or conservative (could) label retention mode. + + - Request, traffic/data, or topology driven label allocation + strategy. + + - Explicit routing (typical), or hop-by-hop routing. + + The GMPLS signaling defines the following new building blocks on the + top of MPLS-TE: + + 1. A new generic label request format. + 2. Labels for TDM, LSC and FSC interfaces, generically known as + Generalized Label. + 3. Waveband switching support. + 4. Label suggestion by the upstream for optimization purposes (e.g., + latency). + 5. Label restriction by the upstream to support some optical + constraints. + 6. Bi-directional LSP establishment with contention resolution. + 7. Rapid failure notification extensions. + 8. Protection information currently focusing on link protection, + plus primary and secondary LSP indication. + 9. Explicit routing with explicit label control for a fine degree of + control. + 10. Specific traffic parameters per technology. + 11. LSP administrative status handling. + 12. Control channel separation. + + These building blocks will be described in more details in the + following. A complete specification can be found in the + corresponding documents. + + Note that GMPLS is highly generic and has many options. Only + building blocks 1, 2 and 10 are mandatory, and only within the + specific format that is needed. Typically, building blocks 6 and 9 + should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are + optional. + + + + + + + +Mannie Standards Track [Page 28] + +RFC 3945 GMPLS Architecture October 2004 + + + A typical SONET/SDH switching network would implement building + blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks + 7 and 8 are optional since the protection can be achieved using + SONET/SDH overhead bytes. + + A typical wavelength switching network would implement building + blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building + block 3 is only needed in the particular case of waveband switching. + + A typical fiber switching network would implement building blocks: + 1, 2 (the generic format), 6, 7, 8, 9 and 11. + + A typical MPLS-IP network would not implement any of these building + blocks, since the absence of building block 1 would indicate regular + MPLS-IP. Note however that building block 1 and 8 can be used to + signal MPLS-IP as well. In that case, the MPLS-IP network can + benefit from the link protection type (not available in CR-LDP, some + very basic form being available in RSVP-TE). Building block 2 is + here a regular MPLS label and no new label format is required. + + GMPLS does not specify any profile for RSVP-TE and CR-LDP + implementations that have to support GMPLS - except for what is + directly related to GMPLS procedures. It is to the manufacturer to + decide which are the optional elements and procedures of RSVP-TE and + CR-LDP that need to be implemented. Some optional MPLS-TE elements + can be useful for TDM, LSC and FSC layers, for instance the setup and + holding priorities that are inherited from MPLS-TE. + +7.1. Overview: How to Request an LSP + + A TDM, LSC or FSC LSP is established by sending a PATH/Label Request + message downstream to the destination. This message contains a + Generalized Label Request with the type of LSP (i.e., the layer + concerned), and its payload type. An Explicit Route Object (ERO) is + also normally added to the message, but this can be added and/or + completed by the first/default LSR. + + The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC + object, or in the CR-LDP Traffic Parameters TLV. Specific parameters + for a given technology are given in these traffic parameters, such as + the type of signal, concatenation and/or transparency for a SONET/SDH + LSP. For some other technology there be could just one bandwidth + parameter indicating the bandwidth as a floating-point value. + + The requested local protection per link may be requested using the + Protection Information Object/TLV. The end-to-end LSP protection is + for further study and is introduced LSP protection/restoration + section (see after). + + + +Mannie Standards Track [Page 29] + +RFC 3945 GMPLS Architecture October 2004 + + + If the LSP is a bi-directional LSP, an Upstream Label is also + specified in the Path/Label Request message. This label will be the + one to use in the upstream direction. + + Additionally, a Suggested Label, a Label Set and a Waveband Label can + also be included in the message. Other operations are defined in + MPLS-TE. + + The downstream node will send back a Resv/Label Mapping message + including one Generalized Label object/TLV that can contain several + Generalized Labels. For instance, if a concatenated SONET/SDH signal + is requested, several labels can be returned. + + In case of SONET/SDH virtual concatenation, a list of labels is + returned. Each label identifying one element of the virtual + concatenated signal. This limits virtual concatenation to remain + within a single (component) link. + + In case of any type of SONET/SDH contiguous concatenation, only one + label is returned. That label is the lowest signal of the contiguous + concatenated signal (given an order specified in [RFC3946]). + + In case of SONET/SDH "multiplication", i.e., co-routing of circuits + of the same type but without concatenation but all belonging to the + same LSP, the explicit ordered list of all signals that take part in + the LSP is returned. + +7.2. Generalized Label Request + + The Generalized Label Request is a new object/TLV to be added in an + RSVP-TE Path message instead of the regular Label Request, or in a + CR-LDP Request message in addition to the already existing TLVs. Only + one label request can be used per message, so a single LSP can be + requested at a time per signaling message. + + The Generalized Label Request gives three major characteristics + (parameters) required to support the LSP being requested: the LSP + Encoding Type, the Switching Type that must be used and the LSP + payload type called Generalized PID (G-PID). + + The LSP Encoding Type indicates the encoding type that will be used + with the data associated with the LSP, i.e., the type of technology + being considered. For instance, it can be SDH, SONET, Ethernet, ANSI + PDH, etc. It represents the nature of the LSP, and not the nature of + the links that the LSP traverses. This is used hop-by-hop by each + node. + + + + + +Mannie Standards Track [Page 30] + +RFC 3945 GMPLS Architecture October 2004 + + + A link may support a set of encoding formats, where support means + that a link is able to carry and switch a signal of one or more of + these encoding formats. The Switching Type indicates then the type + of switching that should be performed on a particular link for that + LSP. This information is needed for links that advertise more than + one type of switching capability. + + Nodes must verify that the type indicated in the Switching Type is + supported on the corresponding incoming interface; otherwise, the + node must generate a notification message with a "Routing + problem/Switching Type" indication. + + The LSP payload type (G-PID) identifies the payload carried by the + LSP, i.e., an identifier of the client layer of that LSP. For some + technologies, it also indicates the mapping used by the client layer, + e.g., byte synchronous mapping of E1. This must be interpreted + according to the LSP encoding type and is used by the nodes at the + endpoints of the LSP to know to which client layer a request is + destined, and in some cases by the penultimate hop. + + Other technology specific parameters are not transported in the + Generalized Label Request but in technology specific traffic + parameters as explained hereafter. Currently, two set of traffic + parameters are defined, one for SONET/SDH and one for G.709. + + Note that it is expected than specific traffic parameters will be + defined in the future for photonic (all optical) switching. + +7.3. SONET/SDH Traffic Parameters + + The GMPLS SONET/SDH traffic parameters [RFC3946] specify a powerful + set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707]. + + The first traffic parameter specifies the type of the elementary + SONET/SDH signal that comprises the requested LSP, e.g., VC-11, VT6, + VC-4, STS-3c, etc. Several transforms can then be applied + successively on the elementary Signal to build the final signal being + actually requested for the LSP. + + These transforms are the contiguous concatenation, the virtual + concatenation, the transparency and the multiplication. Each one is + optional. They must be applied strictly in the following order: + + - First, contiguous concatenation can be optionally applied on the + Elementary Signal, resulting in a contiguously concatenated + signal. + + + + + +Mannie Standards Track [Page 31] + +RFC 3945 GMPLS Architecture October 2004 + + + - Second, virtual concatenation can be optionally applied either + directly on the elementary Signal, or on the contiguously + concatenated signal obtained from the previous phase. + + - Third, some transparency can be optionally specified when + requesting a frame as signal rather than a container. Several + transparency packages are defined. + + - Fourth, a multiplication can be optionally applied either directly + on the elementary Signal, or on the contiguously concatenated + signal obtained from the first phase, or on the virtually + concatenated signal obtained from the second phase, or on these + signals combined with some transparency. + + For RSVP-TE, the SONET/SDH traffic parameters are carried in a new + SENDER_TSPEC and FLOWSPEC. The same format is used for both. There + is no Adspec associated with the SENDER_TSPEC, it is omitted or a + default value is used. The content of the FLOWSPEC object received + in a Resv message should be identical to the content of the + SENDER_TSPEC of the corresponding Path message. In other words, the + receiver is normally not allowed to change the values of the traffic + parameters. However, some level of negotiation may be achieved as + explained in [RFC3946]. + + For CR-LDP, the SONET/SDH traffic parameters are simply carried in a + new TLV. + + Note that a general discussion on SONET/SDH and GMPLS can be found in + [SONET-SDH-GMPLS-FRM]. + +7.4. G.709 Traffic Parameters + + Simply said, an [ITUT-G.709] based network is decomposed in two major + layers: an optical layer (i.e., made of wavelengths) and a digital + layer. These two layers are divided into sub-layers and switching + occurs at two specific sub-layers: at the OCh (Optical Channel) + optical layer and at the ODU (Optical channel Data Unit) electrical + layer. The ODUk notation is used to denote ODUs at different + bandwidths. + + The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful + set of capabilities for ITU-T G.709 networks. + + The first traffic parameter specifies the type of the elementary + G.709 signal that comprises the requested LSP, e.g., ODU1, OCh at 40 + Gbps, etc. Several transforms can then be applied successively on + the elementary Signal to build the final signal being actually + requested for the LSP. + + + +Mannie Standards Track [Page 32] + +RFC 3945 GMPLS Architecture October 2004 + + + These transforms are the virtual concatenation and the + multiplication. Each one of these transforms is optional. They must + be applied strictly in the following order: + + - First, virtual concatenation can be optionally applied directly on + the elementary Signal, + + - Second, a multiplication can be optionally applied, either + directly on the elementary Signal, or on the virtually + concatenated signal obtained from the first phase. + + Additional ODUk Multiplexing traffic parameters allow indicating an + ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. + G.709 supports the following multiplexing capabilities: ODUj into + ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3. + + For RSVP-TE, the G.709 traffic parameters are carried in a new + SENDER-TSPEC and FLOWSPEC. The same format is used for both. There + is no Adspec associated with the SENDER_TSPEC, it is omitted or a + default value is used. The content of the FLOWSPEC object received + in a Resv message should be identical to the content of the + SENDER_TSPEC of the corresponding Path message. + + For CR-LDP, the G.709 traffic parameters are simply carried in a new + TLV. + +7.5. Bandwidth Encoding + + Some technologies that do not have (yet) specific traffic parameters + just require a bandwidth encoding transported in a generic form. + Bandwidth is carried in 32-bit number in IEEE floating-point format + (the unit is bytes per second). Values are carried in a per protocol + specific manner. For non-packet LSPs, it is useful to define + discrete values to identify the bandwidth of the LSP. + + It should be noted that this bandwidth encoding do not apply to + SONET/SDH and G.709, for which the traffic parameters fully define + the requested SONET/SDH or G.709 signal. + + The bandwidth is coded in the Peak Data Rate field of Int-Serv + objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in + the Peak and Committed Data Rate fields of the CR-LDP Traffic + Parameters TLV. + + + + + + + + +Mannie Standards Track [Page 33] + +RFC 3945 GMPLS Architecture October 2004 + + +7.6. Generalized Label + + The Generalized Label extends the traditional MPLS label by allowing + the representation of not only labels that travel in-band with + associated data packets, but also (virtual) labels that identify + time-slots, wavelengths, or space division multiplexed positions. + + For example, the Generalized Label may identify (a) a single fiber in + a bundle, (b) a single waveband within fiber, (c) a single wavelength + within a waveband (or fiber), or (d) a set of time-slots within a + wavelength (or fiber). It may also be a generic MPLS label, a Frame + Relay label, or an ATM label (VCI/VPI). The format of a label can be + as simple as an integer value such as a wavelength label or can be + more elaborated such as an SONET/SDH or a G.709 label. + + SDH and SONET define each a multiplexing structure. These + multiplexing structures will be used as naming trees to create unique + labels. Such a label will identify the exact position (times-lot(s)) + of a signal in a multiplexing structure. Since the SONET + multiplexing structure may be seen as a subset of the SDH + multiplexing structure, the same format of label is used for SDH and + SONET. A similar concept is applied to build a label at the G.709 + ODU layer. + + Since the nodes sending and receiving the Generalized Label know what + kinds of link they are using, the Generalized Label does not identify + its type. Instead, the nodes are expected to know from the context + what type of label to expect. + + A Generalized Label only carries a single level of label i.e., it is + non-hierarchical. When multiple levels of labels (LSPs within LSPs) + are required, each LSP must be established separately. + +7.7. Waveband Switching + + A special case of wavelength switching is waveband switching. A + waveband represents a set of contiguous wavelengths, which can be + switched together to a new waveband. For optimization reasons, it + may be desirable for a photonic cross-connect to optically switch + multiple wavelengths as a unit. This may reduce the distortion on + the individual wavelengths and may allow tighter separation of the + individual wavelengths. A Waveband label is defined to support this + special case. + + Waveband switching naturally introduces another level of label + hierarchy and as such the waveband is treated the same way, all other + upper layer labels are treated. As far as the MPLS protocols are + concerned, there is little difference between a waveband label and a + + + +Mannie Standards Track [Page 34] + +RFC 3945 GMPLS Architecture October 2004 + + + wavelength label. Exception is that semantically the waveband can be + subdivided into wavelengths whereas the wavelength can only be + subdivided into time or statistically multiplexed labels. + + In the context of waveband switching, the generalized label used to + indicate a waveband contains three fields, a waveband ID, a Start + Label and an End Label. The Start and End Labels are channel + identifiers from the sender perspective that identify respectively, + the lowest value wavelength and the highest value wavelength making + up the waveband. + +7.8. Label Suggestion by the Upstream + + GMPLS allows for a label to be optionally suggested by an upstream + node. This suggestion may be overridden by a downstream node but in + some cases, at the cost of higher LSP setup time. The suggested + label is valuable when establishing LSPs through certain kinds of + optical equipment where there may be a lengthy (in electrical terms) + delay in configuring the switching fabric. For example, micro + mirrors may have to be elevated or moved, and this physical motion + and subsequent damping takes time. If the labels and hence switching + fabric are configured in the reverse direction (the norm), the + Resv/MAPPING message may need to be delayed by 10's of milliseconds + per hop in order to establish a usable forwarding path. It can be + important for restoration purposes where alternate LSPs may need to + be rapidly established as a result of network failures. + +7.9. Label Restriction by the Upstream + + An upstream node can optionally restrict (limit) the choice of label + of a downstream node to a set of acceptable labels. Giving lists + and/or ranges of inclusive (acceptable) or exclusive (unacceptable) + labels in a Label Set provides this restriction. If not applied, all + labels from the valid label range may be used. There are at least + four cases where a label restriction is useful in the "optical" + domain. + + Case 1: the end equipment is only capable of transmitting and + receiving on a small specific set of wavelengths/wavebands. + + Case 2: there is a sequence of interfaces, which cannot support + wavelength conversion and require the same wavelength be used + end-to-end over a sequence of hops, or even an entire path. + + Case 3: it is desirable to limit the amount of wavelength conversion + being performed to reduce the distortion on the optical signals. + + Case 4: two ends of a link support different sets of wavelengths. + + + +Mannie Standards Track [Page 35] + +RFC 3945 GMPLS Architecture October 2004 + + + The receiver of a Label Set must restrict its choice of labels to one + that is in the Label Set. A Label Set may be present across multiple + hops. In this case, each node generates its own outgoing Label Set, + possibly based on the incoming Label Set and the node's hardware + capabilities. This case is expected to be the norm for nodes with + conversion incapable interfaces. + +7.10. Bi-directional LSP + + GMPLS allows establishment of bi-directional symmetric LSPs (not of + asymmetric LSPs). A symmetric bi-directional LSP has the same + traffic engineering requirements including fate sharing, protection + and restoration, LSRs, and resource requirements (e.g., latency and + jitter) in each direction. + + In the remainder of this section, the term "initiator" is used to + refer to a node that starts the establishment of an LSP; the term + "terminator" is used to refer to the node that is the target of the + LSP. For a bi-directional LSPs, there is only one initiator and one + terminator. + + Normally to establish a bi-directional LSP when using RSVP-TE + [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be + independently established. This approach has the following + disadvantages: + + 1. The latency to establish the bi-directional LSP is equal to one + round trip signaling time plus one initiator-terminator signaling + transit delay. This not only extends the setup latency for + successful LSP establishment, but it extends the worst-case + latency for discovering an unsuccessful LSP to as much as two + times the initiator-terminator transit delay. These delays are + particularly significant for LSPs that are established for + restoration purposes. + + 2. The control overhead is twice that of a unidirectional LSP. This + is because separate control messages (e.g., Path and Resv) must be + generated for both segments of the bi-directional LSP. + + 3. Because the resources are established in separate segments, route + selection is complicated. There is also additional potential race + for conditions in assignment of resources, which decreases the + overall probability of successfully establishing the bi- + directional connection. + + + + + + + +Mannie Standards Track [Page 36] + +RFC 3945 GMPLS Architecture October 2004 + + + 4. It is more difficult to provide a clean interface for SONET/SDH + equipment that may rely on bi-directional hop-by-hop paths for + protection switching. Note that existing SONET/SDH equipment + transmits the control information in-band with the data. + + 5. Bi-directional optical LSPs (or lightpaths) are seen as a + requirement for many optical networking service providers. + + With bi-directional LSPs both the downstream and upstream data paths, + i.e., from initiator to terminator and terminator to initiator, are + established using a single set of signaling messages. This reduces + the setup latency to essentially one initiator-terminator round trip + time plus processing time, and limits the control overhead to the + same number of messages as a unidirectional LSP. + + For bi-directional LSPs, two labels must be allocated. Bi- + directional LSP setup is indicated by the presence of an Upstream + Label in the appropriate signaling message. + +7.11. Bi-directional LSP Contention Resolution + + Contention for labels may occur between two bi-directional LSP setup + requests traveling in opposite directions. This contention occurs + when both sides allocate the same resources (ports) at effectively + the same time. GMPLS signaling defines a procedure to resolve that + contention: the node with the higher node ID will win the contention. + To reduce the probability of contention, some mechanisms are also + suggested. + +7.12. Rapid Notification of Failure + + GMPLS defines several signaling extensions that enable expedited + notification of failures and other events to nodes responsible for + restoring failed LSPs, and error handling. + + 1. Acceptable Label Set for notification on Label Error: + + There are cases in traditional MPLS and in GMPLS that result in an + error message containing an "Unacceptable label value" indication. + When these cases occur, it can useful for the node generating the + error message to indicate which labels would be acceptable. To + cover this case, GMPLS introduces the ability to convey such + information via the "Acceptable Label Set". An Acceptable Label + Set is carried in appropriate protocol specific error messages. + The format of an Acceptable Label Set is identical to a Label Set. + + + + + + +Mannie Standards Track [Page 37] + +RFC 3945 GMPLS Architecture October 2004 + + + 2. Expedited notification: + + Extensions to RSVP-TE enable expedited notification of failures + and other events to determined nodes. For CR-LDP, there is not + currently a similar mechanism. The first extension identifies + where event notifications are to be sent. The second provides for + general expedited event notification with a Notify message. Such + extensions can be used by fast restoration mechanisms. + Notifications may be requested in both the upstream and downstream + directions. + + The Notify message is a generalized notification mechanism that + differs from the currently defined error messages in that it can + be "targeted" to a node other than the immediate upstream or + downstream neighbor. The Notify message does not replace existing + error messages. The Notify message may be sent either (a) + normally, where non-target nodes just forward the Notify message + to the target node, similar to ResvConf processing in [RFC2205]; + or (b) encapsulated in a new IP header whose destination is equal + to the target IP address. + + 3. Faster removal of intermediate states: + + A specific RSVP optimization allowing in some cases the faster + removal of intermediate states. This extension is used to deal + with specific RSVP mechanisms. + +7.13. Link Protection + + Protection information is carried in the new optional Protection + Information Object/TLV. It currently indicates the desired link + protection for each link of an LSP. If a particular protection type, + i.e., 1+1, or 1:N, is requested, then a connection request is + processed only if the desired protection type can be honored. Note + that GMPLS advertises the protection capabilities of a link in the + routing protocols. Path computation algorithms may consider this + information when computing paths for setting up LSPs. + + Protection information also indicates if the LSP is a primary or + secondary LSP. A secondary LSP is a backup to a primary LSP. The + resources of a secondary LSP are normally not used until the primary + LSP fails, but they may be used by other LSPs until the primary LSP + fails over the secondary LSP. At that point, any LSP that is using + the resources for the secondary LSP must be preempted. + + + + + + + +Mannie Standards Track [Page 38] + +RFC 3945 GMPLS Architecture October 2004 + + + Six link protection types are currently defined as individual flags + and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, + unprotected, extra traffic. See [RFC3471] section 7.1 for a precise + definition of each. + +7.14. Explicit Routing and Explicit Label Control + + By using an explicit route, the path taken by an LSP can be + controlled more or less precisely. Typically, the node at the head- + end of an LSP finds an explicit route and builds an Explicit Route + Object (ERO)/ Explicit Route (ER) TLV that contains that route. + Possibly, the edge node does not build any explicit route, and just + transmit a signaling request to a default neighbor LSR (as IP/MPLS + hosts would). For instance, an explicit route could be added to a + signaling message by the first switching node, on behalf of the edge + node. Note also that an explicit route is altered by intermediate + LSRs during its progression towards the destination. + + The explicit route is originally defined by MPLS-TE as a list of + abstract nodes (i.e., groups of nodes) along the explicit route. + Each abstract node can be an IPv4 address prefix, an IPv6 address + prefix, or an AS number. This capability allows the generator of the + explicit route to have incomplete information about the details of + the path. In the simplest case, an abstract node can be a full IP + address (32 bits) that identifies a specific node (called a simple + abstract node). + + MPLS-TE allows strict and loose abstract nodes. The path between a + strict node and its preceding node must include only network nodes + from the strict node and its preceding abstract node. The path + between a loose node and its preceding abstract node may include + other network nodes that are not part of the loose node or its + preceding abstract node. + + This explicit route was extended to include interface numbers as + abstract nodes to support unnumbered interfaces; and further extended + by GMPLS to include labels as abstract nodes. Having labels in an + explicit route is an important feature that allows controlling the + placement of an LSP with a very fine granularity. This is more + likely to be used for TDM, LSC and FSC links. + + In particular, the explicit label control in the explicit route + allows terminating an LSP on a particular outgoing port of an egress + node. Indeed, a label sub-object/TLV must follow a sub-object/TLV + containing the IP address, or the interface identifier (in case of + unnumbered interface), associated with the link on which it is to be + used. + + + + +Mannie Standards Track [Page 39] + +RFC 3945 GMPLS Architecture October 2004 + + + This can also be used when it is desirable to "splice" two LSPs + together, i.e., where the tail of the first LSP would be "spliced" + into the head of the second LSP. + + When used together with an optimization algorithm, it can provide + very detailed explicit routes, including the label (timeslot) to use + on a link, in order to minimize the fragmentation of the SONET/SDH + multiplex on the corresponding interface. + +7.15. Route Recording + + In order to improve the reliability and the manageability of the LSP + being established, the concept of the route recording was introduced + in RSVP-TE to function as: + + - First, a loop detection mechanism to discover L3 routing loops, or + loops inherent in the explicit route (this mechanism is strictly + exclusive with the use of explicit routing objects). + + - Second, a route recording mechanism collects up-to-date detailed + path information on a hop-by-hop basis during the LSP setup + process. This mechanism provides valuable information to the + source and destination nodes. Any intermediate routing change at + setup time, in case of loose explicit routing, will be reported. + + - Third, a recorded route can be used as input for an explicit + route. This is useful if a source node receives the recorded + route from a destination node and applies it as an explicit route + in order to "pin down the path". + + Within the GMPLS architecture, only the second and third functions + are mainly applicable for TDM, LSC and FSC layers. + +7.16. LSP Modification and LSP Re-routing + + LSP modification and re-routing are two features already available in + MPLS-TE. GMPLS does not add anything new. Elegant re-routing is + possible with the concept of "make-before-break" whereby an old path + is still used while a new path is set up by avoiding double + reservation of resources. Then, the node performing the re-routing + can swap on the new path and close the old path. This feature is + supported with RSVP-TE (using shared explicit filters) and CR-LDP + (using the action indicator flag). + + LSP modification consists in changing some LSP parameters, but + normally without changing the route. It is supported using the same + mechanism as re-routing. However, the semantic of LSP modification + will differ from one technology to the other. For instance, further + + + +Mannie Standards Track [Page 40] + +RFC 3945 GMPLS Architecture October 2004 + + + studies are required to understand the impact of dynamically changing + some SONET/SDH circuit characteristics such as the bandwidth, the + protection type, the transparency, the concatenation, etc. + +7.17. LSP Administrative Status Handling + + GMPLS provides the optional capability to indicate the administrative + status of an LSP by using a new Admin Status object/TLV. + Administrative Status information is currently used in two ways. + + In the first usage, the Admin Status object/TLV is carried in a + Path/Label Request or Resv/Label Mapping message to indicate the + administrative state of an LSP. In this usage, Administrative Status + information indicates the state of the LSP, which include "up" or + "down", if it in a "testing" mode, and if deletion is in progress. + + Based on that administrative status, a node can take local decisions, + like inhibit alarm reporting when an LSP is in "down" or "testing" + states, or report alarms associated with the connection at a priority + equal to or less than "Non service affecting". + + It is possible that some nodes along an LSP will not support the + Admin Status Object/TLV. In the case of a non-supporting transit + node, the object will pass through the node unmodified and normal + processing can continue. + + In some circumstances, particularly optical networks, it is useful to + set the administrative status of an LSP to "being deleted" before + tearing it down in order to avoid non-useful generation of alarms. + The ingress LSR precedes an LSP deletion by inserting an appropriate + Admin Status Object/TLV in a Path/Label Request (with the + modification action indicator flag set to modify) message. Transit + LSRs process the Admin Status Object/TLV and forward it. The egress + LSR answers in a Resv/Label Mapping (with the modification action + indicator flag set to modify) message with the Admin Status object. + Upon receiving this message and object, the ingress node sends a + PathTear/Release message downstream to remove the LSP and normal + RSVP-TE/CR-LDP processing takes place. + + In the second usage, the Admin Status object/TLV is carried in a + Notification/Label Mapping (with the modification action indicator + flag set to modify) message to request that the ingress node change + the administrative state of an LSP. This allows intermediate and + egress nodes triggering the setting of administrative status. In + particular, this allows intermediate or egress LSRs requesting a + release of an LSP initiated by the ingress node. + + + + + +Mannie Standards Track [Page 41] + +RFC 3945 GMPLS Architecture October 2004 + + +7.18. Control Channel Separation + + In GMPLS, a control channel be separated from the data channel. + Indeed, the control channel can be implemented completely out-of- + band for various reason, e.g., when the data channel cannot carry + in-band control information. This issue was even originally + introduced to MPLS in the context of link bundling. + + In traditional MPLS, there is an implicit one-to-one association of a + control channel to a data channel. When such an association is + present, no additional or special information is required to + associate a particular LSP setup transaction with a particular data + channel. + + Otherwise, it is necessary to convey additional information in + signaling to identify the particular data channel being controlled. + GMPLS supports explicit data channel identification by providing + interface identification information. GMPLS allows the use of a + number of interface identification schemes including IPv4 or IPv6 + addresses, interface indexes (for unnumbered interfaces) and + component interfaces (for bundled interfaces), unnumbered bundled + interfaces are also supported. + + The choice of the data interface to use is always made by the sender + of the Path/Label Request message, and indicated by including the + data channel's interface identifier in the message using a new + RSVP_HOP object sub-type/Interface TLV. + + For bi-directional LSPs, the sender chooses the data interface in + each direction. In all cases but bundling, the upstream interface is + implied by the downstream interface. For bundling, the Path/Label + Request sender explicitly identifies the component interface used in + each direction. The new object/TLV is used in Resv/Label Mapping + message to indicate the downstream node's usage of the indicated + interface(s). + + The new object/TLV can contain a list of embedded TLVs, each embedded + TLV can be an IPv4 address, and IPv6 address, an interface index, a + downstream component interface ID or an upstream component interface + ID. In the last three cases, the embedded TLV contains itself an IP + address plus an Interface ID, the IP address being used to identify + the interface ID (it can be the router ID for instance). + + There are cases where it is useful to indicate a specific interface + associated with an error. To support these cases the IF_ID + ERROR_SPEC RSVP Objects are defined. + + + + + +Mannie Standards Track [Page 42] + +RFC 3945 GMPLS Architecture October 2004 + + +8. Forwarding Adjacencies (FA) + + To improve scalability of MPLS TE (and thus GMPLS) it may be useful + to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate + nodes see the external LSP only. They do not have to maintain + forwarding states for each internal LSP, less signaling messages need + to be exchanged and the external LSP can be somehow protected instead + (or in addition) to the internal LSPs. This can considerably + increase the scalability of the signaling. + + The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) + the LSR forming a forwarding adjacency out of that LSP (advertising + this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c) + allowing other LSRs to use forwarding adjacencies for their path + computation, and (d) nesting of LSPs originated by other LSRs into + that LSP (e.g., by using the label stack construct in the case of + IP). + + ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs + just as it floods the information about any other links. Consequently + to this flooding, an LSR has in its TE link state database the + information about not just conventional links, but FAs as well. + + An LSR, when performing path computation, uses not just conventional + links, but FAs as well. Once a path is computed, the LSR uses RSVP- + TE/CR-LDP for establishing label binding along the path. FAs need + simple extensions to signaling and routing protocols. + +8.1. Routing and Forwarding Adjacencies + + Forwarding adjacencies may be represented as either unnumbered or + numbered links. A FA can also be a bundle of LSPs between two nodes. + + FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. + GMPLS TE links are advertised in OSPF and IS-IS such as defined in + [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications + enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link. + + When a FA is created dynamically, its TE attributes are inherited + from the FA-LSP that induced its creation. [HIERARCHY] specifies how + each TE parameter of the FA is inherited from the FA-LSP. Note that + the bandwidth of the FA must be at least as big as the FA-LSP that + induced it, but may be bigger if only discrete bandwidths are + available for the FA-LSP. In general, for dynamically provisioned + forwarding adjacencies, a policy-based mechanism may be needed to + associate attributes to forwarding adjacencies. + + + + + +Mannie Standards Track [Page 43] + +RFC 3945 GMPLS Architecture October 2004 + + + A FA advertisement could contain the information about the path taken + by the FA-LSP associated with that FA. Other LSRs may use this + information for path computation. This information is carried in a + new OSPF and IS-IS TLV called the Path TLV. + + It is possible that the underlying path information might change over + time, via configuration updates, or dynamic route modifications, + resulting in the change of that TLV. + + If forwarding adjacencies are bundled (via link bundling), and if the + resulting bundled link carries a Path TLV, the underlying path + followed by each of the FA-LSPs that form the component links must be + the same. + + It is expected that forwarding adjacencies will not be used for + establishing IS-IS/OSPF peering relation between the routers at the + ends of the adjacency. + + LSP hierarchy could exist both with the peer and with the overlay + models. With the peer model, the LSP hierarchy is realized via FAs + and an LSP is both created and used as a TE link by exactly the same + instance of the control plane. Creating LSP hierarchies with + overlays does not involve the concept of FA. With the overlay model + an LSP created (and maintained) by one instance of the GMPLS control + plane is used as a TE link by another instance of the GMPLS control + plane. Moreover, the nodes using a TE link are expected to have a + routing and signaling adjacency. + +8.2. Signaling Aspects + + For the purpose of processing the explicit route in a Path/Request + message of an LSP that is to be tunneled over a forwarding adjacency, + an LSR at the head-end of the FA-LSP views the LSR at the tail of + that FA-LSP as adjacent (one IP hop away). + +8.3. Cascading of Forwarding Adjacencies + + With an integrated model, several layers are controlled using the + same routing and signaling protocols. A network may then have links + with different multiplexing/demultiplexing capabilities. For + example, a node may be able to multiplex/demultiplex individual + packets on a given link, and may be able to multiplex/demultiplex + channels within a SONET payload on other links. + + A new OSPF and IS-IS sub-TLV has been defined to advertise the + multiplexing capability of each interface: PSC, L2SC, TDM, LSC or + FSC. This sub-TLV is called the Interface Switching Capability + Descriptor sub-TLV, which complements the sub-TLVs defined in + + + +Mannie Standards Track [Page 44] + +RFC 3945 GMPLS Architecture October 2004 + + + [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. The information carried in this + sub-TLV is used to construct LSP regions, and determine region's + boundaries. + + Path computation may take into account region boundaries when + computing a path for an LSP. For example, path computation may + restrict the path taken by an LSP to only the links whose + multiplexing/demultiplexing capability is PSC. When an LSP need to + cross a region boundary, it can trigger the establishment of an FA at + the underlying layer (i.e., the L2SC layer). This can trigger a + cascading of FAs between layers with the following obvious order: + L2SC, then TDM, then LSC, and then finally FSC. + +9. Routing and Signaling Adjacencies + + By definition, two nodes have a routing (IS-IS/OSPF) adjacency if + they are neighbors in the IS-IS/OSPF sense. + + By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency + if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are + RSVP-TE neighbors if they directly exchange RSVP-TE messages + (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of + [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE + Hellos. + + By definition, a Forwarding Adjacency (FA) is a TE Link between two + GMPLS nodes whose path transits one or more other (G)MPLS nodes in + the same instance of the (G)MPLS control plane. If two nodes have + one or more non-FA TE Links between them, these two nodes are + expected (although not required) to have a routing adjacency. If two + nodes do not have any non-FA TE Links between them, it is expected + (although not required) that these two nodes would not have a routing + adjacency. To state the obvious, if the TE links between two nodes + are to be used for establishing LSPs, the two nodes must have a + signaling adjacency. + + If one wants to establish routing and/or signaling adjacency between + two nodes, there must be an IP path between them. This IP path can + be, for example, a TE Link with an interface switching capability of + PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a + (bi-directional) LSP that with an interface switching capability of + PSC). + + A TE link may not be capable of being used directly for maintaining + routing and/or signaling adjacencies. This is because GMPLS routing + and signaling adjacencies requires exchanging data on a per frame/ + packet basis, and a TE link (e.g., a link between OXCs) may not be + capable of exchanging data on a per packet basis. In this case, the + + + +Mannie Standards Track [Page 45] + +RFC 3945 GMPLS Architecture October 2004 + + + routing and signaling adjacencies are maintained via a set of one or + more control channels (see [LMP]). + + Two nodes may have a TE link between them even if they do not have a + routing adjacency. Naturally, each node must run OSPF/IS-IS with + GMPLS extensions in order for that TE link to be advertised. More + precisely, the node needs to run GMPLS extensions for TE Links with + an interface switching capability (see [GMPLS-ROUTING]) other than + PSC. Moreover, this node needs to run either GMPLS or MPLS + extensions for TE links with an interface switching capability of + PSC. + + The mechanisms for Control Channel Separation [RFC3471] should be + used (even if the IP path between two nodes is a TE link). I.e., + RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object + to specify a particular TE link when establishing an LSP. + + The IP path could consist of multiple IP hops. In this case, the + mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used + (in addition to Control Channel Separation). + +10. Control Plane Fault Handling + + Two major types of faults can impact a control plane. The first, + referred to as control channel fault, relates to the case where + control communication is lost between two neighboring nodes. If the + control channel is embedded with the data channel, data channel + recovery procedure should solve the problem. If the control channel + is independent of the data channel, additional procedures are + required to recover from that problem. + + The second, referred to as nodal faults, relates to the case where + node loses its control state (e.g., after a restart) but does not + loose its data forwarding state. + + In transport networks, such types of control plane faults should not + have service impact on the existing connections. Under such + circumstances, a mechanism must exist to detect a control + communication failure and a recovery procedure must guarantee + connection integrity at both ends of the control channel. + + For a control channel fault, once communication is restored routing + protocols are naturally able to recover but the underlying signaling + protocols must indicate that the nodes have maintained their state + through the failure. The signaling protocol must also ensure that + any state changes that were instantiated during the failure are + synchronized between the nodes. + + + + +Mannie Standards Track [Page 46] + +RFC 3945 GMPLS Architecture October 2004 + + + For a nodal fault, a node's control plane restarts and loses most of + its state information. In this case, both upstream and downstream + nodes must synchronize their state information with the restarted + node. In order for any resynchronization to occur the node + undergoing the restart will need to preserve some information, such + as it's mappings of incoming to outgoing labels. + + These issues are addressed in protocol specific fashions, see + [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note that + these cases only apply when there are mechanisms to detect data + channel failures independent of control channel failures. + + The LDP Fault tolerance (see [RFC3479]) specifies the procedures to + recover from a control channel failure. [RFC3473] specifies how to + recover from both a control channel failure and a node failure. + +11. LSP Protection and Restoration + + This section discusses Protection and Restoration (P&R) issues for + GMPLS LSPs. It is driven by the requirements outlined in [RFC3386] + and some of the principles outlined in [RFC3469]. It will be + enhanced, as more GMPLS P&R mechanisms are defined. The scope of + this section is clarified hereafter: + + - This section is only applicable when a fault impacting LSP(s) + happens in the data/transport plane. Section 10 deals with + control plane fault handling for nodal and control channel faults. + + - This section focuses on P&R at the TDM, LSC and FSC layers. There + are specific P&R requirements at these layers not present at the + PSC layer. + + - This section focuses on intra-area P&R as opposed to inter-area + P&R and even inter-domain P&R. Note that P&R can even be more + restricted, e.g., to a collection of like customer equipment, or a + collection of equipment of like capabilities, in one single + routing area. + + - This section focuses on intra-layer P&R (horizontal hierarchy as + defined in [RFC3386]) as opposed to the inter-layer P&R (vertical + hierarchy). + + - P&R mechanisms are in general designed to handle single failures, + which makes SRLG diversity a necessity. Recovery from multiple + failures requires further study. + + - Both mesh and ring-like topologies are supported. + + + + +Mannie Standards Track [Page 47] + +RFC 3945 GMPLS Architecture October 2004 + + + In the following, we assume that: + + - TDM, LSC and FSC devices are more generally committing recovery + resources in a non-best effort way. Recovery resources are either + allocated (thus used) or at least logically reserved (whether used + or not by preemptable extra traffic but unavailable anyway for + regular working traffic). + + - Shared P&R mechanisms are valuable to operators in order to + maximize their network utilization. + + - Sending preemptable excess traffic on recovery resources is a + valuable feature for operators. + +11.1. Protection Escalation across Domains and Layers + + To describe the P&R architecture, one must consider two dimensions of + hierarchy [RFC3386]: + + - A horizontal hierarchy consisting of multiple P&R domains, which + is important in an LSP based protection scheme. The scope of P&R + may extend over a link (or span), an administrative domain or + sub-network, an entire LSP. + + An administrative domain may consist of a single P&R domain or as + a concatenation of several smaller P&R domains. The operator can + configure P&R domains, based on customers' requirements, and on + network topology and traffic engineering constraints. + + - A vertical hierarchy consisting of multiple layers of P&R with + varying granularities (packet flows, STS trails, lightpaths, + fibers, etc). + + In the absence of adequate P&R coordination, a fault may propagate + from one level to the next within a P&R hierarchy. It can lead to + "collisions" and simultaneous recovery actions may lead to race + conditions, reduced resource utilization, or instabilities + [MANCHESTER]. Thus, a consistent escalation strategy is needed to + coordinate recovery across domains and layers. The fact that + GMPLS can be used at different layers could simplify this + coordination. + + There are two types of escalation strategies: bottom-up and top- + down. The bottom-up approach assumes that "lower-level" recovery + schemes are more expedient. Therefore we can inhibit or hold off + + + + + + +Mannie Standards Track [Page 48] + +RFC 3945 GMPLS Architecture October 2004 + + + higher-level P&R. The Top-down approach attempts service P&R at + the higher levels before invoking "lower level" P&R. Higher-layer + P&R is service selective, and permits "per-CoS" or "per-LSP" re- + routing. + + Service Level Agreements (SLAs) between network operators and their + clients are needed to determine the necessary time scales for P&R at + each layer and at each domain. + +11.2. Mapping of Services to P&R Resources + + The choice of a P&R scheme is a tradeoff between network utilization + (cost) and service interruption time. In light of this tradeoff, + network service providers are expected to support a range of + different service offerings or service levels. + + One can classify LSPs into one of a small set of service levels. + Among other things, these service levels define the reliability + characteristics of the LSP. The service level associated with a + given LSP is mapped to one or more P&R schemes during LSP + establishment. An advantage that mapping is that an LSP may use + different P&E schemes in different segments of a network (e.g., some + links may be span protected, whilst other segments of the LSP may + utilize ring protection). These details are likely to be service + provider specific. + + An alternative to using service levels is for an application to + specify the set of specific P&R mechanisms to be used when + establishing the LSP. This allows greater flexibility in using + different mechanisms to meet the application requirements. + + A differentiator between these service levels is service interruption + time in case of network failures, which is defined as the length of + time between when a failure occurs and when connectivity is re- + established. The choice of service level (or P&R scheme) should be + dictated by the service requirements of different applications. + +11.3. Classification of P&R Mechanism Characteristics + + The following figure provides a classification of the possible + provisioning types of recovery LSPs, and of the levels of overbooking + that is possible for them. + + + + + + + + + +Mannie Standards Track [Page 49] + +RFC 3945 GMPLS Architecture October 2004 + + + +-Computed on +-Established +-Resources pre- + | demand | on demand | allocated + | | | + Recovery LSP | | | + Provisioning -+-Pre computed +-Pre established +-Resources allocated + on demand + + +--- Dedicated (1:1, 1+1) + | + | + +--- Shared (1:N, Ring, Shared mesh) + | + Level of | + Overbooking ---+--- Best effort + +11.4. Different Stages in P&R + + Recovery from a network fault or impairment takes place in several + stages as discussed in [RFC3469], including fault detection, fault + localization, notification, recovery (i.e., the P&R itself) and + reversion of traffic (i.e., returning the traffic to the original + working LSP or to a new one). + + - Fault detection is technology and implementation dependent. In + general, failures are detected by lower layer mechanisms (e.g., + SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, + an alarm may be passed up to a GMPLS entity, which will take + appropriate actions, or the alarm may be propagated at the lower + layer (e.g., SONET/SDH AIS). + + - Fault localization can be done with the help of GMPLS, e.g., using + LMP for fault localization (see section 6.4). + + - Fault notification can also be achieved through GMPLS, e.g., using + GMPLS RSVP-TE/CR-LDP notification (see section 7.12). + + - This section focuses on the different mechanisms available for + recovery and reversion of traffic once fault detection, + localization and notification have taken place. + +11.5. Recovery Strategies + + Network P&R techniques can be divided into Protection and + Restoration. In protection, resources between the protection + endpoints are established before failure, and connectivity after + failure is achieved simply by switching performed at the protection + end-points. In contrast, restoration uses signaling after failure to + allocate resources along the recovery path. + + + +Mannie Standards Track [Page 50] + +RFC 3945 GMPLS Architecture October 2004 + + + - Protection aims at extremely fast reaction times and may rely on + the use of overhead control fields for achieving end-point + coordination. Protection for SONET/SDH networks is described in + [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be + further classified by the level of redundancy and sharing. + + - Restoration mechanisms rely on signaling protocols to coordinate + switching actions during recovery, and may involve simple re- + provisioning, i.e., signaling only at the time of recovery; or + pre-signaling, i.e., signaling prior to recovery. + + In addition, P&R can be applied on a local or end-to-end basis. In + the local approach, P&R is focused on the local proximity of the + fault in order to reduce delay in restoring service. In the end-to- + end approach, the LSP originating and terminating nodes control + recovery. + + Using these strategies, the following recovery mechanisms can be + defined. + +11.6. Recovery mechanisms: Protection schemes + + Note that protection schemes are usually defined in technology + specific ways, but this does not preclude other solutions. + + - 1+1 Link Protection: Two pre-provisioned resources are used in + parallel. For example, data is transmitted simultaneously on two + parallel links and a selector is used at the receiving node to + choose the best source (see also [GMPLS-FUNCT]). + + - 1:N Link Protection: Working and protecting resources (N working, + 1 backup) are pre-provisioned. If a working resource fails, the + data is switched to the protecting resource, using a coordination + mechanism (e.g., in overhead bytes). More generally, N working + and M protecting resources can be assigned for M:N link protection + (see also [GMPLS-FUNCT]). + + - Enhanced Protection: Various mechanisms such as protection rings + can be used to enhance the level of protection beyond single link + failures to include the ability to switch around a node failure or + multiple link failures within a span, based on a pre-established + topology of protection resources (note: no reference available at + publication time). + + - 1+1 LSP Protection: Simultaneous data transmission on working and + protecting LSPs and tail-end selection can be applied (see also + [GMPLS-FUNCT]). + + + + +Mannie Standards Track [Page 51] + +RFC 3945 GMPLS Architecture October 2004 + + +11.7. Recovery mechanisms: Restoration schemes + + Thanks to the use of a distributed control plane like GMPLS, + restoration is possible in multiple of tenths of milliseconds. It is + much harder to achieve when only an NMS is used and can only be done + in that case in a multiple of seconds. + + - End-to-end LSP restoration with re-provisioning: an end-to-end + restoration path is established after failure. The restoration + path may be dynamically calculated after failure, or pre- + calculated before failure (often during LSP establishment). + Importantly, no signaling is used along the restoration path + before failure, and no restoration bandwidth is reserved. + Consequently, there is no guarantee that a given restoration path + is available when a failure occurs. Thus, one may have to + crankback to search for an available path. + + - End-to-end LSP restoration with pre-signaled recovery bandwidth + reservation and no label pre-selection: an end-to-end restoration + path is pre-calculated before failure and a signaling message is + sent along this pre-selected path to reserve bandwidth, but labels + are not selected (see also [GMPLS-FUNCT]). + + The resources reserved on each link of a restoration path may be + shared across different working LSPs that are not expected to fail + simultaneously. Local node policies can be applied to define the + degree to which capacity is shared across independent failures. + Upon failure detection, LSP signaling is initiated along the + restoration path to select labels, and to initiate the appropriate + cross-connections. + + - End-to-end LSP restoration with pre-signaled recovery bandwidth + reservation and label pre-selection: An end-to-end restoration + path is pre-calculated before failure and a signaling procedure is + initiated along this pre-selected path on which bandwidth is + reserved and labels are selected (see also [GMPLS-FUNCT]). + + The resources reserved on each link may be shared across different + working LSPs that are not expected to fail simultaneously. In + networks based on TDM, LSC and FSC technology, LSP signaling is + used after failure detection to establish cross-connections at the + intermediate switches on the restoration path using the pre- + selected labels. + + - Local LSP restoration: the above approaches can be applied on a + local basis rather than end-to-end, in order to reduce recovery + time (note: no reference available at publication time). + + + + +Mannie Standards Track [Page 52] + +RFC 3945 GMPLS Architecture October 2004 + + +11.8. Schema Selection Criteria + + This section discusses criteria that could be used by the operator in + order to make a choice among the various P&R mechanisms. + + - Robustness: In general, the less pre-planning of the restoration + path, the more robust the restoration scheme is to a variety of + failures, provided that adequate resources are available. + Restoration schemes with pre-planned paths will not be able to + recover from network failures that simultaneously affect both the + working and restoration paths. Thus, these paths should ideally + be chosen to be as disjoint as possible (i.e., SRLG and node + disjoint), so that any single failure event will not affect both + paths. The risk of simultaneous failure of the two paths can be + reduced by recalculating the restoration path whenever a failure + occurs along it. + + The pre-selection of a label gives less flexibility for multiple + failure scenarios than no label pre-selection. If failures occur + that affect two LSPs that are sharing a label at a common node + along their restoration routes, then only one of these LSPs can be + recovered, unless the label assignment is changed. + + The robustness of a restoration scheme is also determined by the + amount of reserved restoration bandwidth - as the amount of + restoration bandwidth sharing increases (reserved bandwidth + decreases), the restoration scheme becomes less robust to + failures. Restoration schemes with pre-signaled bandwidth + reservation (with or without label pre-selection) can reserve + adequate bandwidth to ensure recovery from any specific set of + failure events, such as any single SRLG failure, any two SRLG + failures etc. Clearly, more restoration capacity is allocated if + a greater degree of failure recovery is required. Thus, the + degree to which the network is protected is determined by the + policy that defines the amount of reserved restoration bandwidth. + + - Recovery time: In general, the more pre-planning of the + restoration route, the more rapid the P&R scheme. Protection + schemes generally recover faster than restoration schemes. + Restoration with pre-signaled bandwidth reservation are likely to + be (significantly) faster than path restoration with re- + provisioning, especially because of the elimination of any + crankback. Local restoration will generally be faster than end- + to-end schemes. + + + + + + + +Mannie Standards Track [Page 53] + +RFC 3945 GMPLS Architecture October 2004 + + + Recovery time objectives for SONET/SDH protection switching (not + including time to detect failure) are specified in [ITUT-G.841] at + 50 ms, taking into account constraints on distance, number of + connections involved, and in the case of ring enhanced protection, + number of nodes in the ring. + + Recovery time objectives for restoration mechanisms are being + defined through a separate effort [RFC3386]. + + - Resource Sharing: 1+1 and 1:N link and LSP protection require + dedicated recovery paths with limited ability to share resources: + 1+1 allows no sharing, 1:N allows some sharing of protection + resources and support of extra (pre-emptable) traffic. + Flexibility is limited because of topology restrictions, e.g., + fixed ring topology for traditional enhanced protection schemes. + + The degree to which restoration schemes allow sharing amongst + multiple independent failures is directly dictated by the size of + the restoration pool. In restoration schemes with re- + provisioning, a pool of restoration capacity can be defined from + which all restoration routes are selected after failure. Thus, + the degree of sharing is defined by the amount of available + restoration capacity. In restoration with pre-signaled bandwidth + reservation, the amount of reserved restoration capacity is + determined by the local bandwidth reservation policies. In all + restoration schemes, pre-emptable resources can use spare + restoration capacity when that capacity is not being used for + failure recovery. + +12. Network Management + + Service Providers (SPs) use network management extensively to + configure, monitor or provision various devices in their network. It + is important to note that a SP's equipment may be distributed across + geographically separate sites thus making distributed management even + more important. The service provider should utilize an NMS system + and standard management protocols such as SNMP (see [RFC3410], + [RFC3411] and [RFC3416]) and the relevant MIB modules as standard + interfaces to configure, monitor and provision devices at various + locations. The service provider may also wish to use the command + line interface (CLI) provided by vendors with their devices. However, + this is not a standard or recommended solution because there is no + standard CLI language or interface, which results in N different CLIs + in a network with devices from N different vendors. In the context of + GMPLS, it is extremely important for standard interfaces to the SP's + devices (e.g., SNMP) to exist due to the nature of the technology + itself. Since GMPLS comprises many different layers of control-plane + + + + +Mannie Standards Track [Page 54] + +RFC 3945 GMPLS Architecture October 2004 + + + and data-plane technology, it is important for management interfaces + in this area to be flexible enough to allow the manager to manage + GMPLS easily, and in a standard way. + +12.1. Network Management Systems (NMS) + + The NMS system should maintain the collective information about each + device within the system. Note that the NMS system may actually be + comprised of several distributed applications (i.e., alarm + aggregators, configuration consoles, polling applications, etc.) + that collectively comprises the SP's NMS. In this way, it can make + provisioning and maintenance decisions with the full knowledge of the + entire SP's network. Configuration or provisioning information + (i.e., requests for new services) could be entered into the NMS and + subsequently distributed via SNMP to the remote devices. Thus, + making the SP's task of managing the network much more compact and + effortless rather than having to manage each device individually + (i.e., via CLI). + + Security and access control can be achieved using the SNMPv3 User- + based Security Model (USM) [RFC3414] and the View-based Access + Control Model (VACM) [RFC3415]. This approach can be very + effectively used within a SP's network, since the SP has access to + and control over all devices within its domain. Standardized MIBs + will need to be developed before this approach can be used + ubiquitously to provision, configure and monitor devices in non- + heterogeneous networks or across SP's network boundaries. + +12.2. Management Information Base (MIB) + + In the context of GMPLS, it is extremely important for standard + interfaces to devices to exist due to the nature of the technology + itself. Since GMPLS comprises many different layers of control-plane + technology, it is important for SNMP MIB modules in this area to be + flexible enough to allow the manager to manage the entire control + plane. This should be done using MIB modules that may cooperate + (i.e., coordinated row-creation on the agent) or through more + generalized MIB modules that aggregate some of the desired actions to + be taken and push those details down to the devices. It is important + to note that in certain circumstances, it may be necessary to + duplicate some small subset of manageable objects in new MIB modules + for management convenience. Control of some parts of GMPLS may also + be achieved using existing MIB interfaces (i.e., existing SONET MIB) + or using separate ones, which are yet to be defined. MIB modules may + have been previously defined in the IETF or ITU. Current MIB modules + may need to be extended to facilitate some of the new functionality + + + + + +Mannie Standards Track [Page 55] + +RFC 3945 GMPLS Architecture October 2004 + + + desired by GMPLS. In these cases, the working group should work on + new versions of these MIB modules so that these extensions can be + added. + +12.3. Tools + + As in traditional networks, standard tools such as traceroute + [RFC1393] and ping [RFC2151] are needed for debugging and performance + monitoring of GMPLS networks, and mainly for the control plane + topology, that will mimic the data plane topology. Furthermore, such + tools provide network reachability information. The GMPLS control + protocols will need to expose certain pieces of information in order + for these tools to function properly and to provide information + germane to GMPLS. These tools should be made available via the CLI. + These tools should also be made available for remote invocation via + the SNMP interface [RFC2925]. + +12.4. Fault Correlation between Multiple Layers + + Due to the nature of GMPLS, and that potential layers may be involved + in the control and transmission of GMPLS data and control + information, it is required that a fault in one layer be passed to + the adjacent higher and lower layers to notify them of the fault. + However, due to nature of these many layers, it is possible and even + probable, that hundreds or even thousands of notifications may need + to transpire between layers. This is undesirable for several + reasons. First, these notifications will overwhelm the device. + Second, if the device(s) are programmed to emit SNMP Notifications + [RFC3417] then the large number of notifications the device may + attempt to emit may overwhelm the network with a storm of + notifications. Furthermore, even if the device emits the + notifications, the NMS that must process these notifications either + will be overwhelmed or will be processing redundant information. That + is, if 1000 interfaces at layer B are stacked above a single + interface below it at layer A, and the interface at A goes down, the + interfaces at layer B should not emit notifications. Instead, the + interface at layer A should emit a single notification. The NMS + receiving this notification should be able to correlate the fact that + this interface has many others stacked above it and take appropriate + action, if necessary. + + Devices that support GMPLS should provide mechanisms for aggregating, + summarizing, enabling and disabling of inter-layer notifications for + the reasons described above. In the context of SNMP MIB modules, all + MIB modules that are used by GMPLS must provide enable/disable + objects for all notification objects. Furthermore, these MIBs must + also provide notification summarization objects or functionality (as + described above) as well. NMS systems and standard tools which + + + +Mannie Standards Track [Page 56] + +RFC 3945 GMPLS Architecture October 2004 + + + process notifications or keep track of the many layers on any given + devices must be capable of processing the vast amount of information + which may potentially be emitted by network devices running GMPLS at + any point in time. + +13. Security Considerations + + GMPLS defines a control plane architecture for multiple technologies + and types of network elements. In general, since LSPs established + using GMPLS may carry high volumes of data and consume significant + network resources, security mechanisms are required to safeguard the + underlying network against attacks on the control plane and/or + unauthorized usage of data transport resources. The GMPLS control + plane should therefore include mechanisms that prevent or minimize + the risk of attackers being able to inject and/or snoop on control + traffic. These risks depend on the level of trust between nodes that + exchange GMPLS control messages, as well as the realization and + physical characteristics of the control channel. For example, an in- + band, in-fiber control channel over SONET/SDH overhead bytes is, in + general, considered less vulnerable than a control channel realized + over an out-of-band IP network. + + Security mechanisms can provide authentication and confidentiality. + Authentication can provide origin verification, message integrity and + replay protection, while confidentiality ensures that a third party + cannot decipher the contents of a message. In situations where GMPLS + deployment requires primarily authentication, the respective + authentication mechanisms of the GMPLS component protocols may be + used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). Additionally, + the IPsec suite of protocols (see [RFC2402], [RFC2406] and [RFC2409]) + may be used to provide authentication, confidentiality or both, for a + GMPLS control channel. IPsec thus offers the benefits of combined + protection for all GMPLS component protocols as well as key + management. + + A related issue is that of the authorization of requests for + resources by GMPLS-capable nodes. Authorization determines whether a + given party, presumable already authenticated, has a right to access + the requested resources. This determination is typically a matter of + local policy control [RFC2753], for example by setting limits on the + total bandwidth available to some party in the presence of resource + contention. Such policies may become quite complex as the number of + users, types of resources and sophistication of authorization rules + increases. + + After authenticating requests, control elements should match them + against the local authorization policy. These control elements must + be capable of making decisions based on the identity of the + + + +Mannie Standards Track [Page 57] + +RFC 3945 GMPLS Architecture October 2004 + + + requester, as verified cryptographically and/or topologically. For + example, decisions may depend on whether the interface through which + the request is made is an inter- or intra-domain one. The use of + appropriate local authorization policies may help in limiting the + impact of security breaches in remote parts of a network. + + Finally, it should be noted that GMPLS itself introduces no new + security considerations to the current MPLS-TE signaling (RSVP-TE, + CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management + protocols (SNMP). + +14. Acknowledgements + + This document is the work of numerous authors and consists of a + composition of a number of previous documents in this area. + + Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH + discussions we had together. Thanks also to Pedro Falcao, Alexandre + Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from + Ebone for their SONET/SDH and optical technical advice and support. + Finally, many thanks also to Krishna Mitra (Consultant), Curtis + Villamizar (Avici), Ron Bonica (WorldCom), and Bert Wijnen (Lucent) + for their revision effort on Section 12. + +15. References + +15.1. Normative References + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", + RFC 3031, January 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., + Srinivasan, V., and G. Swallow, "RSVP-TE: + Extensions to RSVP for LSP Tunnels", RFC 3209, + December 2001. + + [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, + R., Wu, L., Doolan, P., Worster, T., Feldman, + N., Fredette, A., Girish, M., Gray, E., + Heinanen, J., Kilty, T., and A. Malis, + "Constraint-Based LSP Setup using LDP", RFC + 3212, January 2002. + + [RFC3471] Berger, L., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional + Description", RFC 3471, January 2003. + + + + +Mannie Standards Track [Page 58] + +RFC 3945 GMPLS Architecture October 2004 + + + [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized + Multi-Protocol Label Switching (GMPLS) + Signaling Constraint-based Routed Label + Distribution Protocol (CR-LDP) Extensions", RFC + 3472, January 2003. + + [RFC3473] Berger, L., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource + ReserVation Protocol-Traffic Engineering + (RSVP-TE) Extensions", RFC 3473, January 2003. + +15.2. Informative References + + [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic + Description Including Multiplex Structure, + Rates, And Formats," ANSI T1.105, 2000. + + [BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link + Bundling in MPLS Traffic Engineering", Work in + Progress. + + [GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed., + "Generalized MPLS Recovery Functional + Specification", Work in Progress. + + [GMPLS-G709] Papadimitriou, D., Ed., "GMPLS Signaling + Extensions for G.709 Optical Transport Networks + Control", Work in Progress. + + [GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. + Rekhter, "GMPLS UNI: RSVP Support for the + Overlay Model", Work in Progress. + + [GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi- + Protocol Label Switching", Work in Progress. + + [RFC3946] Mannie, E., Ed. and Papadimitriou D., Ed., + "Generalized Multi-Protocol Label Switching + (GMPLS) Extensions for Synchronous Optical + Network (SONET) and Synchronous Digital + Hierarchy (SDH) Control", RFC 3946, October + 2004. + + [HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy + with Generalized MPLS TE", Work in Progress. + + + + + +Mannie Standards Track [Page 59] + +RFC 3945 GMPLS Architecture October 2004 + + + [ISIS-TE] Smit, H. and T. Li, "Intermediate System to + Intermediate System (IS-IS) Extensions for + Traffic Engineering (TE)", RFC 3784, June 2004. + + [ISIS-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS + Extensions in Support of Generalized Multi- + Protocol Label Switching", Work in Progress. + + [ITUT-G.707] ITU-T, "Network Node Interface for the + Synchronous Digital Hierarchy", Recommendation + G.707, October 2000. + + [ITUT-G.709] ITU-T, "Interface for the Optical Transport + Network (OTN)," Recommendation G.709 version + 1.0 (and Amendment 1), February 2001 (and + October 2001). + + [ITUT-G.841] ITU-T, "Types and Characteristics of SDH + Network Protection Architectures," + Recommendation G.841, October 1998. + + [LMP] Lang, J., Ed., "Link Management Protocol + (LMP)", Work in Progress. + + [LMP-WDM] Fredette, A., Ed. and J. Lang Ed., "Link + Management Protocol (LMP) for Dense Wavelength + Division Multiplexing (DWDM) Optical Line + Systems", Work in Progress. + + [MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The + Evolution of Transport Network Survivability," + IEEE Communications Magazine, August 1999. + + [OIF-UNI] The Optical Internetworking Forum, "User + Network Interface (UNI) 1.0 Signaling + Specification - Implementation Agreement OIF- + UNI-01.0," October 2001. + + [OLI-REQ] Fredette, A., Ed., "Optical Link Interface + Requirements," Work in Progress. + + [OSPF-TE-GMPLS] Kompella, K., Ed. and Y. + Rekhter, Ed., "OSPF Extensions in Support of + Generalized Multi-Protocol Label Switching", + Work in Progress. + + + + + + +Mannie Standards Track [Page 60] + +RFC 3945 GMPLS Architecture October 2004 + + + [OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic + Engineering (TE) Extensions to OSPF Version 2", + RFC 3630, September 2003. + + [RFC1393] Malkin, G., "Traceroute Using an IP Option", + RFC 1393, January 1993. + + [RFC2151] Kessler, G. and S. Shepard, "A Primer On + Internet and TCP/IP Tools and Utilities", RFC + 2151, June 1997. + + [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., + and S. Jamin, "Resource ReSerVation Protocol + (RSVP) -- Version 1 Functional Specification", + RFC 2205, September 1997. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via + the TCP MD5 Signature Option", RFC 2385, August + 1998. + + [RFC2402] Kent, S. and R. Atkinson, "IP Authentication + Header", RFC 2402, November 1998. + + [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating + Security Payload (ESP)", RFC 2406, November + 1998. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC2702] Awduche, D., Malcolm, J., + Agogbua, J., O'Dell, M., and J. McManus, + "Requirements for Traffic Engineering Over + MPLS", RFC 2702, September 1999. + + [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP + Cryptographic Authentication", RFC 2747, + January 2000. + + [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A + Framework for Policy-based Admission Control", + RFC 2753, January 2000. + + [RFC2925] White, K., "Definitions of Managed Objects for + Remote Ping, Traceroute, and Lookup + Operations", RFC 2925, September 2000. + + + + + +Mannie Standards Track [Page 61] + +RFC 3945 GMPLS Architecture October 2004 + + + [RFC3036] Andersson, L., Doolan, P., Feldman, N., + Fredette, A., and B. Thomas, "LDP + Specification", RFC 3036, January 2001. + + [RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and + Multilayer Survivability", RFC 3386, November + 2002. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. + Stewart, "Introduction and Applicability + Statements for Internet-Standard Management + Framework", RFC 3410, December 2002. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network + Management Protocol (SNMP) Management + Frameworks", STD 62, RFC 3411, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based + Security Model (USM) for version 3 of the + Simple Network Management Protocol (SNMPv3)", + STD 62, RFC 3414, December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, + "View-based Access Control Model (VACM) for the + Simple Network Management Protocol (SNMP)", STD + 62, RFC 3415, December 2002. + + [RFC3416] Presuhn, R., "Version 2 of the Protocol + Operations for the Simple Network Management + Protocol (SNMP)", STD 62, RFC 3416, December + 2002. + + [RFC3417] Presuhn, R., "Transport Mappings for the Simple + Network Management Protocol (SNMP)", STD 62, + RFC 3417, December 2002. + + [RFC3469] Sharma, V. and F. Hellstrand, "Framework for + Multi-Protocol Label Switching (MPLS)-based + Recovery", RFC 3469, February 2003. + + [RFC3477] Kompella, K. and Y. Rekhter, "Signalling + Unnumbered Links in Resource ReSerVation + Protocol - Traffic Engineering (RSVP-TE)", RFC + 3477, January 2003. + + + + + + +Mannie Standards Track [Page 62] + +RFC 3945 GMPLS Architecture October 2004 + + + [RFC3479] Farrel, A., "Fault Tolerance for the Label + Distribution Protocol (LDP)", RFC 3479, + February 2003. + + [RFC3480] Kompella, K., Rekhter, Y., and A. Kullberg, + "Signalling Unnumbered Links in CR-LDP + (Constraint-Routing Label Distribution + Protocol)", RFC 3480, February 2003. + + [SONET-SDH-GMPLS-FRM] Bernstein, G., Mannie, E., and V. Sharma, + "Framework for GMPLS-based Control of SDH/SONET + Networks", Work in Progress. + +16. Contributors + + Peter Ashwood-Smith + Nortel + P.O. Box 3511 Station C, + Ottawa, ON K1Y 4H7, Canada + + EMail: petera@nortelnetworks.com + + + Eric Mannie + Consult + Phone: +32 2 648-5023 + Mobile: +32 (0)495-221775 + + EMail: eric_mannie@hotmail.com + + + Daniel O. Awduche + Consult + + EMail: awduche@awduche.com + + + Thomas D. Nadeau + Cisco + 250 Apollo Drive + Chelmsford, MA 01824, USA + + EMail: tnadeau@cisco.com + + + + + + + + +Mannie Standards Track [Page 63] + +RFC 3945 GMPLS Architecture October 2004 + + + Ayan Banerjee + Calient + 5853 Rue Ferrari + San Jose, CA 95138, USA + + EMail: abanerjee@calient.net + + + Lyndon Ong + Ciena + 10480 Ridgeview Ct + Cupertino, CA 95014, USA + + EMail: lyong@ciena.com + + + Debashis Basak + Accelight + 70 Abele Road, Bldg.1200 + Bridgeville, PA 15017, USA + + EMail: dbasak@accelight.com + + + Dimitri Papadimitriou + Alcatel + Francis Wellesplein, 1 + B-2018 Antwerpen, Belgium + + EMail: dimitri.papadimitriou@alcatel.be + + + Lou Berger + Movaz + 7926 Jones Branch Drive + MCLean VA, 22102, USA + + EMail: lberger@movaz.com + + + Dimitrios Pendarakis + Tellium + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + + EMail: dpendarakis@tellium.com + + + + + +Mannie Standards Track [Page 64] + +RFC 3945 GMPLS Architecture October 2004 + + + Greg Bernstein + Grotto + + EMail: gregb@grotto-networking.com + + + Bala Rajagopalan + Tellium + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + + EMail: braja@tellium.com + + + Sudheer Dharanikota + Consult + + EMail: sudheer@ieee.org + + + Yakov Rekhter + Juniper + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089, USA + + EMail: yakov@juniper.net + + + John Drake + Calient + 5853 Rue Ferrari + San Jose, CA 95138, USA + + EMail: jdrake@calient.net + + + Debanjan Saha + Tellium + 2 Crescent Place + Oceanport, NJ 07757-0901, USA + + EMail: dsaha@tellium.com + + + + + + + + + +Mannie Standards Track [Page 65] + +RFC 3945 GMPLS Architecture October 2004 + + + Yanhe Fan + Axiowave + 200 Nickerson Road + Marlborough, MA 01752, USA + + EMail: yfan@axiowave.com + + + Hal Sandick + Shepard M.S. + 2401 Dakota Street + Durham, NC 27705, USA + + EMail: sandick@nc.rr.com + + + Don Fedyk + Nortel + 600 Technology Park Drive + Billerica, MA 01821, USA + + EMail: dwfedyk@nortelnetworks.com + + + Vishal Sharma + Metanoia + 1600 Villa Street, Unit 352 + Mountain View, CA 94041, USA + + EMail: v.sharma@ieee.org + + Gert Grammel + Alcatel + Lorenzstrasse, 10 + 70435 Stuttgart, Germany + + EMail: gert.grammel@alcatel.de + + + George Swallow + Cisco + 250 Apollo Drive + Chelmsford, MA 01824, USA + + EMail: swallow@cisco.com + + + + + + +Mannie Standards Track [Page 66] + +RFC 3945 GMPLS Architecture October 2004 + + + Dan Guo + Turin + 1415 N. McDowell Blvd, + Petaluma, CA 95454, USA + + EMail: dguo@turinnetworks.com + + + Z. Bo Tang + Tellium + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + + EMail: btang@tellium.com + + + Kireeti Kompella + Juniper + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089, USA + + EMail: kireeti@juniper.net + + + Jennifer Yates + AT&T + 180 Park Avenue + Florham Park, NJ 07932, USA + + EMail: jyates@research.att.com + + Alan Kullberg + NetPlane + 888 Washington + St.Dedham, MA 02026, USA + + EMail: akullber@netplane.com + + + George R. Young + Edgeflow + 329 March Road + Ottawa, Ontario, K2K 2E1, Canada + + EMail: george.young@edgeflow.com + + + + + + +Mannie Standards Track [Page 67] + +RFC 3945 GMPLS Architecture October 2004 + + + Jonathan P. Lang + Rincon Networks + + EMail: jplang@ieee.org + + + John Yu + Hammerhead Systems + 640 Clyde Court + Mountain View, CA 94043, USA + + EMail: john@hammerheadsystems.com + + + Fong Liaw + Solas Research + Solas Research, LLC + + EMail: fongliaw@yahoo.com + + + Alex Zinin + Alcatel + 1420 North McDowell Ave + Petaluma, CA 94954, USA + + EMail: alex.zinin@alcatel.com + +17. Author's Address + + Eric Mannie (Consultant) + Avenue de la Folle Chanson, 2 + B-1050 Brussels, Belgium + Phone: +32 2 648-5023 + Mobile: +32 (0)495-221775 + + EMail: eric_mannie@hotmail.com + + + + + + + + + + + + + + +Mannie Standards Track [Page 68] + +RFC 3945 GMPLS Architecture October 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the IETF's procedures with respect to + rights in IETF Documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Mannie Standards Track [Page 69] + |