--- 1/draft-ietf-ccamp-gmpls-architecture-06.txt 2006-02-04 22:55:23.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-architecture-07.txt 2006-02-04 22:55:23.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group Eric Mannie - Editor Internet Draft Category: Standard Track - Expiration date: October 2003 April 2003 + Expiration date: November 2003 May 2003 Generalized Multi-Protocol Label Switching Architecture - draft-ietf-ccamp-gmpls-architecture-06.txt + draft-ietf-ccamp-gmpls-architecture-07.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -77,42 +77,42 @@ 6.4. Unnumbered Bundled Link .................................... 17 6.5. Forming Bundled Links ...................................... 17 7. Relationship with the UNI .................................... 18 7.1. Relationship with the OIF UNI .............................. 18 7.2. Reachability across the UNI ................................ 19 8. Link Management .............................................. 19 8.1. Control Channel and Control Channel Management ............. 20 8.2. Link Property Correlation .................................. 21 8.3. Link Connectivity Verification ............................. 21 8.4. Fault Management ........................................... 22 - 8.5 LMP for DWDM Optical Line Systems (OLSs) .................... 22 + 8.5. LMP for DWDM Optical Line Systems (OLSs) ................... 23 9. Generalized Signaling ........................................ 24 9.1. Overview: How to Request an LSP ............................ 25 9.2. Generalized Label Request .................................. 26 9.3. SONET/SDH Traffic Parameters ............................... 27 9.4. G.709 Traffic Parameters ................................... 28 9.5. Bandwidth Encoding ......................................... 29 9.6. Generalized Label .......................................... 29 9.7. Waveband Switching ......................................... 30 9.8. Label Suggestion by the Upstream ........................... 30 9.9. Label Restriction by the Upstream .......................... 31 9.10. Bi-directional LSP ........................................ 31 9.11. Bi-directional LSP Contention Resolution .................. 32 - 9.12. Rapid Notification of Failure ............................. 32 + 9.12. Rapid Notification of Failure ............................. 33 9.13. Link Protection ........................................... 33 9.14. Explicit Routing and Explicit Label Control ............... 34 9.15. Route Recording ........................................... 35 9.16. LSP Modification and LSP Re-routing ....................... 35 9.17. LSP Administrative Status Handling ........................ 36 + 9.18. Control Channel Separation ................................ 36 E. Mannie (Editor) et al. Standard Track 2 - 9.18. Control Channel Separation ................................ 36 10. Forwarding Adjacencies (FA) ................................. 37 10.1. Routing and Forwarding Adjacencies ........................ 38 10.2. Signaling Aspects ......................................... 39 10.3. Cascading of Forwarding Adjacencies ....................... 39 11. Routing and Signaling Adjacencies ........................... 39 12. Control Plane Fault Handling ................................ 40 13. LSP Protection and Restoration .............................. 41 13.1. Protection Escalation across Domains and Layers ........... 42 13.2. Mapping of Services to P&R Resources ...................... 43 13.3. Classification of P&R Mechanism Characteristics ........... 43 @@ -127,61 +127,61 @@ 14.3. Tools ..................................................... 49 14.4. Fault Correlation Between Multiple Layers ................. 49 15. Security Considerations ..................................... 50 16. Acknowledgements ............................................ 51 17. Intellectual Property Considerations ........................ 51 18. References .................................................. 51 18.1 Normative References ....................................... 51 18.2 Information References ..................................... 54 19. Author's Address ............................................ 55 20. Contributors ................................................ 55 - Full Copyright Statement ........................................ 57 + Full Copyright Statement ........................................ 58 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Introduction - The architecture presented in this document covers the main building + 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 E. Mannie (Editor) et al. Standard Track 3 - 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 draft is as follows. We + 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. 3.1. Acronyms & Abbreviations AS Autonomous System BGP Border Gateway Protocol @@ -208,23 +208,23 @@ STS(-N) Synchronous Transport Signal-Level N (SONET) TDM Time Division Multiplexing TE Traffic Engineering 3.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 E. Mannie (Editor) et al. Standard Track 4 - 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 @@ -330,80 +330,80 @@ E. Mannie (Editor) et al. Standard Track 6 The GMPLS control plane is made of several building blocks are described in more detail 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. This, because most of the technologies that - can be used below the PSC level requires some 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. + MPLS, a.k.a. MPLS-TE [RFC2702]. This, because most of the + technologies that can be used below the PSC level requires some + 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 ISIS/OSPF Link + 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 and CR-LDP. 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. + 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 is based on RSVP-TE and CR-LDP, it mandates a + Since GMPLS signalling 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. E. Mannie (Editor) et al. Standard Track 7 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 and IS-IS- - 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. + 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. @@ -667,47 +667,46 @@ It is expected that they will first be developed for MPLS and later on generalized to GMPLS. A TE link between a pair of LSRs doesn't 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 ISIS adjacencies are established "control channels". + or IS-IS adjacencies are established "control channels". 5. 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 ISIS-TE and OSPF-TE. + 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 [RSVP-TE-UNNUM] and CR-LDP [CR-LDP- - UNNUM]. The MPLS-TE signaling doesn't provide support for - unnumbered links, because it doesn't 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. + requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480]. The + MPLS-TE signaling doesn't provide support for unnumbered links, + because it doesn't 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/CR-LDP (especially in the case + 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 @@ -719,21 +718,21 @@ 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 ISIS-TE and for the TE LSA (which 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. 5.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. @@ -795,25 +794,25 @@ 6.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 Tunnel specification) 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. + 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. Note that advertising a (bundled) TE link between a pair of LSRs doesn't 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 @@ -831,21 +830,21 @@ 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. 6.3. Signaling Considerations Typically, an LSP's explicit route (e.g. contained in an explicit - route TLV/Object) will choose the bundled link to be used for the + 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. @@ -860,46 +859,46 @@ 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. 6.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 [RSVP-TE-GMPLS]/[CR-LDP-GMPLS], respectively). For a bi- - directional LSP, a component link is provided for each direction by - the upstream node. + (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 doesn't even require the whole (bundled) link to have its own control channel. 6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID -E. Mannie (Editor) et al. Standard Track 16 With this mechanism, each component link that is unnumbered is assigned a unique Interface Identifier (32 bits value). The upstream + +E. Mannie (Editor) et al. Standard Track 16 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 - [RSVP-TE-GMPLS] [CR-LDP-GMPLS]. + (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/CR-LDP (especially in the case where a - component link is a Forwarding Adjacency), or by means of IS-IS or + 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 doesn't even require the whole (bundled) link to have its own control channel. 6.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 @@ -924,24 +923,25 @@ 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). -E. Mannie (Editor) et al. Standard Track 17 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 + +E. Mannie (Editor) et al. Standard Track 17 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. 7. Relationship with the UNI @@ -978,25 +978,24 @@ 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 - -E. Mannie (Editor) et al. Standard Track 18 concatenation, the transparency level as well as the type of diversity (node, link, SRLG) supported by the network. +E. Mannie (Editor) et al. Standard Track 18 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. 7.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. @@ -1034,36 +1033,36 @@ - 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. 8. 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 - -E. Mannie (Editor) et al. Standard Track 19 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 + +E. Mannie (Editor) et al. Standard Track 19 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) 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. + (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. 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 @@ -1090,26 +1089,25 @@ 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 - -E. Mannie (Editor) et al. Standard Track 20 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. +E. Mannie (Editor) et al. Standard Track 20 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. 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 @@ -1139,50 +1137,48 @@ 8.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 to add component links to a link bundle, - change a link's protection mechanism, change port identifiers, or - change component identifiers in a bundle. This mechanism is - supported by an exchange of link summary messages. + change link's minimum/maximum reservable bandwidth, change port + identifiers, or change component identifiers in a bundle. This + mechanism is supported by an exchange of link summary messages. 8.3. Link Connectivity Verification -E. Mannie (Editor) et al. Standard Track 21 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. - The use of this procedure is negotiated as part of the configuration - exchange that take place during the negotiation phase of the Hello - protocol. This procedure should be done initially when a data- - bearing link is first established, and subsequently, on a periodic - basis for all unallocated (free) data-bearing links. +E. Mannie (Editor) et al. Standard Track 21 + 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 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. + 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. @@ -1200,83 +1196,82 @@ 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). -E. Mannie (Editor) et al. Standard Track 22 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). +E. Mannie (Editor) et al. Standard Track 22 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. 8.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 and OXC + 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 [GMPLS-SIG]), can be used to suppress spurious alarms. For + 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. 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 - -E. Mannie (Editor) et al. Standard Track 23 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. +E. Mannie (Editor) et al. Standard Track 23 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 @@ -1289,48 +1284,49 @@ 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 [GMPLS-SIG]. - 2. RSVP-TE extensions [RSVP-TE-GMPLS]. - 3. CR-LDP extensions [CR-LDP-GMPLS]. + 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 [GMPLS-SONET-SDH]. 2. GMPLS extensions for G.709 control [GMPLS-G709]. 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: -E. Mannie (Editor) et al. Standard Track 24 1. A new generic label request format. 2. Labels for TDM, LSC and FSC interfaces, generically known as Generalized Label. 3. Waveband switching support. + +E. Mannie (Editor) et al. Standard Track 24 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. @@ -1343,22 +1339,22 @@ 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. 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/restoration can be - achieved using SONET/SDH overhead bytes. + 7 and 8 are optional since 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 @@ -1366,27 +1362,26 @@ 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 - -E. Mannie (Editor) et al. Standard Track 25 can be useful for TDM, LSC and FSC layers, for instance the setup and holding priorities that are inherited from MPLS-TE. 9.1. Overview: How to Request an LSP +E. Mannie (Editor) et al. Standard Track 25 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 @@ -1422,27 +1417,27 @@ label is returned. That label is the lowest signal of the contiguous concatenated signal (given an order specified in [GMPLS-SONET-SDH]). 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. 9.2. Generalized Label Request -E. Mannie (Editor) et al. Standard Track 26 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. +E. Mannie (Editor) et al. Standard Track 26 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 @@ -1472,31 +1467,30 @@ 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. 9.3. SONET/SDH Traffic Parameters The GMPLS SONET/SDH traffic parameters [GMPLS-SONET-SDH] specify a - powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T - G.707). + powerful set of capabilities for SONET [ANSI T1.105] and SDH [ITU-T + 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, - -E. Mannie (Editor) et al. Standard Track 27 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. +E. Mannie (Editor) et al. Standard Track 27 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. - Second, virtual concatenation can be optionally applied either directly on the elementary Signal, or on the contiguously concatenated signal obtained from the previous phase. @@ -1520,63 +1514,62 @@ explained in [GMPLS-SONET-SDH]. 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]. 9.4. G.709 Traffic Parameters - Simply said, an ITU-T 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. + Simply said, an [ITU-T 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 - -E. Mannie (Editor) et al. Standard Track 28 Gbps, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP. +E. Mannie (Editor) et al. Standard Track 28 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 SONET/SDH traffic parameters are carried in a new + 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 SONET/SDH traffic parameters are simply carried in a - new TLV. + For CR-LDP, the G.709 traffic parameters are simply carried in a new + TLV. 9.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. @@ -1589,25 +1582,26 @@ the Peak and Committed Data Rate fields of the CR-LDP Traffic Parameters TLV. 9.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. -E. Mannie (Editor) et al. Standard Track 29 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, + +E. Mannie (Editor) et al. Standard Track 29 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 @@ -1645,24 +1639,25 @@ 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. 9.8. Label Suggestion by the Upstream -E. Mannie (Editor) et al. Standard Track 30 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 + +E. Mannie (Editor) et al. Standard Track 30 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. @@ -1699,29 +1694,29 @@ 9.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 - -E. Mannie (Editor) et al. Standard Track 31 "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] or - [CR-LDP] two unidirectional paths must be independently established. - This approach has the following disadvantages: +E. Mannie (Editor) et al. Standard Track 31 + 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 @@ -1754,25 +1749,25 @@ directional LSP setup is indicated by the presence of an Upstream Label in the appropriate signaling message. 9.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 - -E. Mannie (Editor) et al. Standard Track 32 contention. To reduce the probability of contention, some mechanisms are also suggested. +E. Mannie (Editor) et al. Standard Track 32 + 9.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. @@ -1792,53 +1787,52 @@ 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 [RSVP]; or (b) encapsulated in a - new IP header whose destination is equal to the target IP address. + 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. 9.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 - -E. Mannie (Editor) et al. Standard Track 33 routing protocols. Path computation algorithms may consider this information when computing paths for setting up LSPs. +E. Mannie (Editor) et al. Standard Track 33 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. 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 [GMPLS-SIG] section 7.1 for a - precise definition of each. + unprotected, extra traffic. See [RFC3471] section 7.1 for a precise + definition of each. 9.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 @@ -1865,26 +1859,25 @@ 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 - -E. Mannie (Editor) et al. Standard Track 34 containing the IP address, or the interface identifier (in case of unnumbered interface), associated with the link on which it is to be used. +E. Mannie (Editor) et al. Standard Track 34 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. 9.15. Route Recording @@ -1921,25 +1914,25 @@ 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 studies are required to understand the impact of dynamically changing some SONET/SDH circuit characteristics such as the - -E. Mannie (Editor) et al. Standard Track 35 bandwidth, the protection type, the transparency, the concatenation, etc. +E. Mannie (Editor) et al. Standard Track 35 + 9.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 @@ -1960,57 +1953,58 @@ 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/CR-LDP processing takes place. + 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. 9.18. Control Channel Separation In GMPLS, a control channel can 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. -E. Mannie (Editor) et al. Standard Track 36 In traditional MPLS, there is an implicit one-to-one association of a control channel to a data channel. When such an association is + +E. Mannie (Editor) et al. Standard Track 36 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 + data channel's interface identifier in the message using a new IF_ID 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). @@ -2030,46 +2024,45 @@ 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 don't 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 ISIS/OSPF), (c) + this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path - -E. Mannie (Editor) et al. Standard Track 37 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 +E. Mannie (Editor) et al. Standard Track 37 + IS-IS/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. 10.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 ISIS such as defined in + 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 @@ -2083,30 +2076,30 @@ 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 ISIS/OSPF peering relation between the routers at the + 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 - -E. Mannie (Editor) et al. Standard Track 38 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 doesn't involve the concept of FA. With the overlay model + +E. Mannie (Editor) et al. Standard Track 38 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. 10.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 @@ -2133,35 +2126,36 @@ 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. 11. Routing and Signaling Adjacencies - By definition, two nodes have a routing (ISIS/OSPF) adjacency if - they are neighbors in the ISIS/OSPF sense. + 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. -E. Mannie (Editor) et al. Standard Track 39 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 + +E. Mannie (Editor) et al. Standard Track 39 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 @@ -2171,110 +2165,108 @@ 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 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 don't have a - routing adjacency. Naturally, each node must run OSPF/ISIS with + 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 [GMPLS-SIG] should be + 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). 12. 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. -E. Mannie (Editor) et al. Standard Track 40 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. +E. Mannie (Editor) et al. Standard Track 40 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. 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 [RSVP- - TE-GMPLS], [CR-LDP-GMPLS], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note - that these cases only apply when there are mechanisms to detect data + 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 [LDP-FT]) specifies the procedures to - recover from a control channel failure. [RSVP-TE-GMPLS] specifies - how to recover from both a control channel failure and a node - failure. + 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. 13. 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 11 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 - -E. Mannie (Editor) et al. Standard Track 41 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). +E. Mannie (Editor) et al. Standard Track 41 - 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. 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 @@ -2308,26 +2300,27 @@ 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. -E. Mannie (Editor) et al. Standard Track 42 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 higher-level P&R. The Top-down approach attempts service P&R at the higher levels before invoking "lower level" P&R. Higher-layer + +E. Mannie (Editor) et al. Standard Track 42 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. 13.2. Mapping of Services to P&R Resources The choice of a P&R scheme is a tradeoff between network utilization @@ -2363,25 +2356,26 @@ provisioning types of recovery LSPs, and of the levels of overbooking that is possible for them. +-Computed on +-Established +-Resources pre- | demand | on demand | allocated | | | Recovery LSP | | | Provisioning -+-Pre computed +-Pre established +-Resources allocated on demand -E. Mannie (Editor) et al. Standard Track 43 +--- Dedicated (1:1, 1+1) | | +--- Shared (1:N, Ring, Shared mesh) + +E. Mannie (Editor) et al. Standard Track 43 | Level of | Overbooking ---+--- Best effort 13.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 @@ -2417,24 +2411,25 @@ 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. -E. Mannie (Editor) et al. Standard Track 44 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- + +E. Mannie (Editor) et al. Standard Track 44 end approach, the LSP originating and terminating nodes control recovery. Using these strategies, the following recovery mechanisms can be defined. 13.6. Recovery mechanisms: Protection schemes Note that protection schemes are usually defined in technology specific ways, but this does not preclude other solutions. @@ -2472,24 +2467,25 @@ - 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. -E. Mannie (Editor) et al. Standard Track 45 - 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 + +E. Mannie (Editor) et al. Standard Track 45 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. @@ -2527,24 +2523,25 @@ 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. -E. Mannie (Editor) et al. Standard Track 46 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 + +E. Mannie (Editor) et al. Standard Track 46 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. @@ -2760,21 +2757,21 @@ 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). 16. Acknowledgements - This draft is the work of numerous authors and consists of a + This document is the work of numerous authors and consists of a composition of a number of previous drafts 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 its revision effort of Section 14. @@ -2805,182 +2802,210 @@ 18. References 18.1 Normative References [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, And Formats," ANSI T1.105, 2000. E. Mannie (Editor) et al. Standard Track 51 [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling - in MPLS Traffic Engineering," Work in Progress. - - [CR-LDP] B.Jamoussi (Editor) et al., "Constraint-Based LSP - Setup using LDP," IETF RFC 3212, January 2002. - - [CR-LDP-GMPLS] P.Ashwood-Smith and L.Berger (Editors) et al., - "Generalized MPLS Signaling - CR-LDP Extensions," - IETF RFC 3472, January 2003. - - [CR-LDP-UNNUM] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling - Unnumbered Links in CR-LDP," Work in Progress. + in MPLS Traffic Engineering," Work in Progress, + draft-ietf-mpls-bundle-04.txt. [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., "Generalized MPLS Recovery Functional - Specification," Work in Progress. + Specification," Work in Progress, draft-ietf-ccamp- + gmpls-recovery-functional-01.txt. [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling Extensions for G.709 Optical Transport Networks - Control," Work in progress. + Control," Work in progress, draft-ietf-ccamp-gmpls- + g709-03.txt. [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the - Overlay Model," Work in Progress. + Overlay Model," Work in Progress, draft-ietf-ccamp- + gmpls-overlay-01.txt. [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing Extensions in Support of Generalized MPLS," Work in - Progress. - - [GMPLS-SIG] L.Berger (Editor) et al., "Generalized MPLS - - Signaling Functional Description," IETF RFC 3471, - January 2003. + Progress, draft-ietf-ccamp-gmpls-routing-05.txt. [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., "Generalized MPLS Extensions for SONET and SDH - Control," Work in progress. + Control," Work in progress, draft-ietf-ccamp-gmpls- + sonet-sdh-08.txt. [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with - Generalized MPLS TE," Work in Progress. + Generalized MPLS TE," Work in Progress, draft-ietf- + mpls-lsp-hierarchy-08.txt. + + [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. - [LDP-FT] A.Farrel (Editor) et al., "Fault Tolerance for the - Label Distribution Protocol (LDP)," IETF RFC 3479, - February 2003. - [LMP] J.P.Lang (Editor) et al., "Link Management Protocol - (LMP)," Work in progress. + (LMP)," Work in progress, draft-ietf-ccamp-lmp- + 09.txt. [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for WDM Optical Line Systems (LMP-WDM)," Work in - progress. + progress, draft-ietf-ccamp-lmp-wdm-02.txt. -E. Mannie (Editor) et al. Standard Track 52 [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions - in Support of Generalized MPLS," Work in Progress. + in Support of Generalized MPLS," Work in Progress, + +E. Mannie (Editor) et al. Standard Track 52 + draft-ietf-ccamp-ospf-gmpls-extensions-09.txt. [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic - Engineering Extensions to OSPF", Work in Progress. + Engineering Extensions to OSPF", Work in Progress, + draft-katz-yeung-ospf-traffic-09.txt. [RFC1393] G.Malkin, "Traceroute Using an IP Option", IETF RFC 1393, January 1993. [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3," BCP 9, IETF RFC 2026, October 1996. [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, IETF RFC 2119, March 1997. [RFC2151] G.Kessler and S.Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", IETF RFC 2151, June 1997. [RFC2385] A.Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option," IETF RFC 2385, August 1998. [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," IETF RFC 2402, November 1998. [RFC2406] S.Kent and R. Atkinson, "IP Encapsulating Security - Payload (ESP)", IETF RFC 2406, November 1998. + Payload (ESP)," IETF RFC 2406, November 1998. [RFC2409] D.Harkins and D.Carrel, "The Internet Key Exchange - (IKE)", IETF RFC 2409, November 1998. + (IKE)," IETF RFC 2409, November 1998. [RFC2747] F.Baker et al., "RSVP Cryptographic Authentication," IETF RFC 2747, January 2000. [RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for Policy-based Admission Control," IETF RFC 2753, January 2000. [RFC2925] K.White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations," IETF RFC 2925, September 2000. [RFC3031] E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol Label Switching Architecture," IETF RFC 3031, January 2001. [RFC3036] L.Andersson, P.Doolan, N.Feldman, A.Fredette, and B.Thomas, "LDP Specification," IETF RFC 3036, January 2001. + [RFC3209] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for + LSP Tunnels," IETF RFC 3209, December 2001. + + [RFC3212] B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup + using LDP," IETF RFC 3212, January 2002. + +E. Mannie (Editor) et al. Standard Track 53 [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks," IETF RFC 3411, December 2002. -E. Mannie (Editor) et al. Standard Track 53 [RFC3414] U.Blumenthal and B.Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)," IETF RFC 3414, December 2002. [RFC3415] B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)," IETF RFC 3415, December 2002. [RFC3416] R.Presuhn (Editor), "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)," IETF RFC 3416, December 2002. [RFC3417] R.Presuhn (Editor), "Transport Mappings for the Simple Network Management Protocol (SNMP)," IETF RFC 3417, December 2002. - [RSVP-TE] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for - LSP Tunnels," IETF RFC 3209, December 2001. + [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered + Links in Resource ReSerVation Protocol - Traffic + Engineering (RSVP-TE)," IETF RFC 3477, January 2003. - [RSVP-TE-GMPLS] L.Berger (Editor) et al., "Generalized MPLS - Signaling - RSVP-TE Extensions," IETF RFC 3473, + [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - + Signaling Functional Description," IETF RFC 3471, January 2003. - [RSVP-TE-UNNUM] K.Kompella and Y.Rekhter, "Signalling Unnumbered - Links in Resource ReSerVation Protocol - Traffic - Engineering (RSVP-TE)," IETF RFC 3477, January 2003. + [RFC3472] P.Ashwood-Smith and L.Berger (Editors) et al., + "Generalized MPLS Signaling - CR-LDP Extensions," IETF + RFC 3472, January 2003. + + [RFC3473] L.Berger (Editor) et al., "Generalized MPLS + Signaling - RSVP-TE Extensions," IETF RFC 3473, January + 2003. + + [RFC3479] A.Farrel (Editor) et al., "Fault Tolerance for the + Label Distribution Protocol (LDP)," IETF RFC 3479, + February 2003. + + [RFC3480] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling + Unnumbered Links in CR-LDP," IETF RFC 3480, February + 2003. 18.2 Informative References [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic - Engineering," Work in Progress. + Engineering," Work in Progress, draft-ietf-isis- + traffic-04.txt. [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS + +E. Mannie (Editor) et al. Standard Track 54 Extensions in Support of Generalized MPLS," Work in - Progress. + Progress, draft-ietf-isis-gmpls-extensions-16.txt. [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution of Transport Network Survivability," IEEE - Communications, August 1999. + 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] A.Fredette (Editor), "Optical Link Interface Requirements," Work in Progress. + [RFC2702] D.Awduche, et al., "Requirements for Traffic + Engineering Over MPLS," IETF RFC 2702, September 1999. + [RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and Multi- layer Survivability," IETF RFC 3386, November 2002. [RFC3410] J.Case, R.Mundy, D.Partain, and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework," IETF RFC 3410, December 2002. -E. Mannie (Editor) et al. Standard Track 54 [RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery," IETF RFC 3469, February 2003. [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma, "Framework for GMPLS-based Control of SDH/SONET Networks," Work in Progress. 19. Author's Address @@ -2994,20 +3019,21 @@ Peter Ashwood-Smith (Nortel) Eric Mannie (Consult) P.O. Box 3511 Station C, Phone: +32 2 648-5023 Ottawa, ON K1Y 4H7, Canada Mobile: +32 (0)495-221775 Email: petera@nortelnetworks.com Email: eric_mannie@hotmail.com Daniel O. Awduche (Consult) Thomas D. Nadeau (Cisco) Email: awduche@awduche.com 250 Apollo Drive Chelmsford, MA 01824, USA Email: tnadeau@cisco.com +E. Mannie (Editor) et al. Standard Track 55 Ayan Banerjee (Calient) Lyndon Ong (Ciena) 5853 Rue Ferrari 10480 Ridgeview Ct San Jose, CA 95138, USA Cupertino, CA 95014, USA Email: abanerjee@calient.net Email: lyong@ciena.com Debashis Basak (Accelight) Dimitri Papadimitriou (Alcatel) 70 Abele Road, Bldg.1200 Francis Wellesplein, 1 Bridgeville, PA 15017, USA B-2018 Antwerpen, Belgium Email: dbasak@accelight.com Email: dimitri.papadimitriou@alcatel.be @@ -3020,25 +3046,24 @@ Greg Bernstein (Grotto) Bala Rajagopalan (Tellium) Email: 2 Crescent Place, P.O. Box 901 gregb@grotto-networking.com Oceanport, NJ 07757-0901, USA Email: braja@tellium.com Sudheer Dharanikota (Consult) Yakov Rekhter (Juniper) Email: sudheer@ieee.org 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA Email: yakov@juniper.net -E. Mannie (Editor) et al. Standard Track 55 - John Drake (Calient) Debanjan Saha (Tellium) - 5853 Rue Ferrari 2 Crescent Place - San Jose, CA 95138, USA Oceanport, NJ 07757-0901, USA - Email: jdrake@calient.net Email: dsaha@tellium.com + John Drake (Calient) Debanjan Saha + 5853 Rue Ferrari (IBM Watson Research Center) + San Jose, CA 95138, USA Email: dsaha@us.ibm.com + Email: jdrake@calient.net Yanhe Fan (Axiowave) Hal Sandick 200 Nickerson Road Shepard M.S. Marlborough, MA 01752, USA 2401 Dakota Street Email: yfan@axiowave.com Durham, NC 27705, USA Email: sandick@nc.rr.com Don Fedyk (Nortel) Vishal Sharma (Metanoia) 600 Technology Park Drive 1600 Villa Street, Unit 352 Billerica, MA 01821, USA Mountain View, CA 94041, USA @@ -3048,41 +3073,42 @@ Gert Grammel (Alcatel) George Swallow (Cisco) Lorenzstrasse, 10 250 Apollo Drive 70435 Stuttgart, Germany Chelmsford, MA 01824, USA Email: gert.grammel@alcatel.de Email: swallow@cisco.com Dan Guo (Turin) Z. Bo Tang (Tellium) 1415 N. McDowell Blvd, Petaluma, 2 Crescent Place, P.O. Box 901 CA 95454, USA Oceanport, NJ 07757-0901, USA Email: dguo@turinnetworks.com Email: btang@tellium.com +E. Mannie (Editor) et al. Standard Track 56 Kireeti Kompella (Juniper) Jennifer Yates (AT&T) 1194 N. Mathilda Ave. 180 Park Avenue Sunnyvale, CA 94089, USA Florham Park, NJ 07932, USA Email: kireeti@juniper.net Email: jyates@research.att.com Alan Kullberg (NetPlane) George R. Young (Edgeflow) 888 Washington 329 March Road St.Dedham, MA 02026, USA Ottawa, Ontario, K2K 2E1, Canada Email: akullber@netplane.com Email: george.young@edgeflow.com Jonathan P. Lang John Yu (Hammerhead Systems) (Rincon Networks) 640 Clyde Court Email: jplang@ieee.org Mountain View, CA 94043, USA Email: john@hammerheadsystems.com Fong Liaw (Solas Research) Alex Zinin (Alcatel) Solas Research, LLC 1420 North McDowell Ave Email: fongliaw@yahoo.com Petaluma, CA 94954, USA Email: alex.zinin@alcatel.com -E. Mannie (Editor) et al. Standard Track 56 +E. Mannie (Editor) et al. Standard Track 57 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this @@ -3097,11 +3123,11 @@ The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." -E. Mannie (Editor) et al. Standard Track 57 +E. Mannie (Editor) et al. Standard Track 58