Network Working Group K. Shiomoto
(NTT)(Ed.) Internet Draft R. Rabbat (Google)NTT Updates: 3477, 4206 A. Ayyangar (Juniper Networks)Farrel (Ed.) Proposed Category: Proposed Standard A. Farrel (OldOld Dog Consulting) Z. Ali (Cisco Systems, Inc.) Expires: AugustConsulting Created: October 15, 2008 February 22,Expires: April 15, 2008 Procedures for Dynamically Signaled Hierarchical Label Switched Paths draft-ietf-ccamp-lsp-hierarchy-bis-03.txtdraft-ietf-ccamp-lsp-hierarchy-bis-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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.Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- DraftsInternet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 22,2008.Abstract This document discusses topics related to hierarchical and stitched GeneralizedLabel Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Label Switched Paths (LSPs). It describesnetworks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to allowfacilitate the establishment of an egress to identify that a bi-directionalLSP will be usedas a dynamically signaled Forwarding Adjacency LSP (FA-LSP) ornumbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a RoutingForwarding Adjacency (RA). In addition, the(FA). This document extends those mechanisms to support unnumbered FAs. This document also discusses the issue ofdefines how to indicate that an LSP should be advertised as a traffic engineering (TE)link into a differentin another instance of the IGP,routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and howto identify the instance that should be used.bundle. 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]. Table of Contents 1. Introduction and Problem Statement..........................3Statement ............................. 1 1.1. Background ................................................... 1.1.1. Hierarchical LSPs .......................................... 1.1.2. LSP Hierarchy............................................3Stitching Segments ..................................... 1.1.3. Private Links .............................................. 1.1.4. Routing Adjacencies ........................................ 1.1.5. Forwarding Adjacencies ..................................... 1.1.5. Client/Server Networks ..................................... 1.1.6. Link Bundles ............................................... 1.2. LSP advertisement and Usage...............................4Desired Function ............................................. 1.3. Problem Statement........................................6 1.4. Current ApproachesExisting Mechanisms .......................................... 1.3.1. LSP Setup .................................................. 1.3.2. Routing Adjacency Establishment and Shortcomings.......................8 1.5. ContentsLink State Advertisement 1.3.3. TE Link Advertisement ...................................... 1.3.4. Configuration and Management Techniques .................... 1.3.5. Signaled Unnumbered FAs .................................... 1.3.6. Establishing Numbered FAs Through Signaling and Routing .... 1.4. Overview of This Document.................................9Required Extensions .............................. 1.4.1. Efficient Signaling of Numbered FAs ........................ 1.4.2. LSPs for Use as Private Links .............................. 1.4.3. Signaling an LSP For use in Another Network ................ 1.4.4. Signaling an LSP for Use in a Link Bundle .................. 1.4.5. Support for IPv4 and IPv6 .................................. 1.4.6. Backward Compatibility ..................................... 2. Revision history...........................................9Overview of Solution ........................................... 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9Common Approach for Numbered and Unnumbered Links ............ 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9LSP Usage Indication ......................................... 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02.10 3. Proposed Solution..........................................10 3.1.IGP Instance Identification...............................11 3.2. LSP advertisementIdentification .................................. 2.4. Link Bundle Identification ................................... 2.5. Backward Compatibility ....................................... 3. Mechanisms and Usage Identification................11 3.3. Bundling.................................................12 3.4.Protocol Extensions ............................. 3.1. LSP_TUNNEL_INTERFACE_ID Object............................12 3.4.1. Unnumbered link.........................................13 3.4.2.Object ............................... 3.1.1. Existing Definition and Usage .............................. 3.1.2. Unnumbered Links with Action Identification ................ 3.1.3. IPv4 numbered link......................................14 3.4.3.Numbered Links with Action Identification ............. 3.1.4. IPv6 numbered link......................................15 3.4.4. Unnumbered linkNumbered Links with targetAction Identification ............. 3.2. Target IGP instance identifier......16 3.4.5. Message Formats........................................16 3.5. TLVs.....................................................17 3.5.1.Identification TLV ................................ 3.3. Component Link Identification TLV ............................ 3.3.1. Unnumbered Component Link Identifier....................17 3.5.2. IPv4Identification ................... 3.3.2. Numbered Component Link Identifier.................18Identification ..................... 3.4. Link State Advertisement ..................................... 3.5. Message Formats .............................................. 3.6. LSA advertisement........................................18 4. Applicability Statement.....................................19 5.Error Cases and Non-Acceptance ............................... 3.7. Backward Compatibility Considerations.......................19 6........................................ 4. Security Considerations.....................................19 7.Considerations ........................................ 5. IANA Considerations........................................20 8. Acknowledgement............................................20 9. References.................................................20 9.1.Considerations ............................................ 5.1. New Class Types .............................................. 5.2. Hierarchy Actions ............................................ 5.3. New Error Codes and Error Values ............................. 6. Acknowledgements ............................................... 7. References ..................................................... 7.1. Normative References.....................................20 9.2.References ......................................... 7.2. Informative References....................................20 Author's Addresses............................................21 Intellectual Property Statement................................22 Copyright Statement...........................................23References ....................................... 8. Editors' Addresses ............................................. 9. Authors' Addresses ............................................. 1. Introduction and Problem Statement 1.1. LSP Hierarchy LSP hierarchy has been developed[RFC4206] defines how to improve the scalability ofset up Label Switched Paths (LSPs) in Generalized Multi-ProtocolMultiprotocol Label Switching (GMPLS) by allowingTraffic Engineering (TE) networks to be used as hierarchical Label Switched Paths (LSPs)(H-LSPs). [RFC4201] describes how to be aggregated into a hierarchy of such LSPs [RFC4206]. An LSP may be advertised as a traffic engineering (TE) link for use withincollect together TE links between the same instancepair of the control planenodes and advertise them as was used to set up the LSP. Thisa single TE link iscalled a Forwarding Adjacency (FA),link bundle. [RFC5212] presents a framework and the LSP is known as an FA-LSP. [RFC4206] defines the operation as followsrequirements for a numbered FA: 1. The ingress signalsmultilayer networks (MLNs). This includes the establishment of an LSP usingin a /31 sender addressserver network that it allocatesis used as the source addressa link in the signaling message (tunnel sender addressa client network. As set out later in the Sender Template object of the Path message),this document, issues have been identified during deployment with how LSPs are established and targeting the TE router IDmade available for use as H-LSPs or as components of the egress (destination addressa link bundle and advertised appropriately in an interior gateway protocol (IGP). These issues relate to coordinating between the Sender object ofLSP's end points the Path message). 2. The egress sets upuse to which the LSP using normal procedures and allocating the partner address of the assigned /31 address inis put. This document gives some basic background, describes the local interface address. 3. The ingress then forms a Forwarding Adjacency (FA)requirements, sets out of that LSP by advertising it as a Traffic Engineering (TE) link usingthe routing protocol (OSPF/ISIS)mechanisms that already exist, and usingenumerates the /31 addressprotocols extensions and mechanisms that are needed. The document goes on to identify the local end of the TE link. 4. When the egress receivespresent the TE link advertisement, it checksnecessary additions to the Link-ID addressGMPLS protocols. 1.1. Background 1.1.1. Hierarchical LSPs [RFC3031] describes how Multiprotocol Label Switching (MPLS) labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of the TE advertisement against its own TE Router ID. If it matches its own TE Router ID, the egress checks the advertising router IDH-LSPs is formalized in [RFC4206] with a set of protocol mechanisms for the TE advertisement against the ingress addressesestablishment of allan H-LSP that can carry one or more other LSPs. [RFC4206] goes on to explain that an H-LSP may carry other LSPs for which itonly according to their switching types. This is a function of the egress and findsway labels are carried. In a packet switch capable (PSC) network, the address match withH-LSP can carry other PSC LSPs using the advertising router ID ofMPLS label stack. In non- packet networks where the TE advertisement. 5. The egress then advertiseslabel is implicit, label stacks are not possible and rely on the FAability to nest switching technologies. Thus, for example, a lambda switch capable (LSC) LSP can carry a time division multiplexing (TDM) LSP, but cannot carry another LSC LSP. Signaling mechanisms defined in [RFC4206] allow an H-LSP to be treated as a TE link setting the advertising TE Router IDsingle hop in the Link-ID and the partner addresspath of another LSP (i.e., one hop of the assigned /31 address in the local interface address. Nesting of LSPs originated by other LSRs into thatLSP can be achievedcarried by usingthe label stack construct. 1.2.H-LSP). This mechanism is known as "non- adjacent signaling." 1.1.2. LSP advertisement and Usage There are three different ways in which traffic can be forwarded to There are different ways in which anStitching Segments LSP can be used to carry traffic and potentially advertised as a link by a routing protocol. First,stitching is defined in [RFC5150]. It enables LSPs of the LSP cansame switching type to be used eitherincluded (stitched) as a link inside or outside the network that was used to form thehops in an end-to-end LSP. In the former case, theThe stitching LSP can carry traffic that could have been routed down the TE links that are navigated by the LSP. In the latter case, it(S-LSP) is used by a client network, which is provided on top of the network [MLN-REQ]. It can provide a new, virtual, point-to-point linkin a client network. The former case can only be achievedthe control plane in packet networksthe same way as they arean H-LSP, but in the only type of networkdata plane the LSPs are stitched so that supportsthere is no label stacking or nesting of LSPs withintechnologies. Thus, an S-LSP must be of the same switching technology LSP, but the latter case is applicable to all client/server network relationships suchas IP over MPLS, or packet over optical. Second, the link formed bythe end-to-end LSP can be advertised by the routing protocol as available to carry traffic,that it facilitates. 1.1.3. Private Links An H-LSP or S-LSP can be keptused as a private linklink. Such links are known onlyby their end-points, but are not more widely known. They can be used to carry traffic between the head and tail end LSRs. These two options give riseend-points, but are not usually used to four possible combinations as follows. 1. The LSPcarry traffic that is created and advertised as a TE link ingoing beyond the same instanceegress of the routing protocol as was used to advertise the links that it traverses. This is a Forwarding Adjacency as described in [RFC4206]. Note that noLSP. 1.1.4. Routing Adjacencies A routing adjacency is formed overbetween two IGP-speakers that are logically adjacent. In this sense, 'logically adjacent' means that the LSP. 2.routers have a protocol tunnel between them through which they can exchange routing protocol messages. The LSPtunnel is created and madealso usually available to carryfor carrying IP data although a distinction should be made in GMPLS networks between data plane traffic and control plane traffic. Routing adjacencies for forwarding data traffic are only relevant in PSC networks (i.e., IP/MPLS networks). 1.1.5. Forwarding Adjacencies A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same network asinstance of the linkscontrol plane that it traverses, but it is not advertised. The availability ofadvertises the LSP is private toTE links from which the end points. ThisLSP is a hierarchical LSP, but not an FA. It might be used for inter-domain traffic engineering [RFC4726]. 3.constructed. The LSP itself is created as before, butcalled an FA-LSP. Thus, an H-LSP or S-LSP may form an FA such that it is advertised as a TE link in anotherthe same instance of the routing protocol. This method of operation is particularprotocol as was used to client/server networks and especially multi-layer networks [MLN-REQ], [PCE-INTER-LAYER-REQ]. 4.advertise the TE links that the LSP traverses. As observed in [RFC4206] the nodes at the ends of an FA would not usually have a routing adjacency. 1.1.5. Client/Server Networks An LSP canmay be created in one network and used byas a client network without being advertisedlink (sometimes called a virtual link) in another networks [RFC5212]. In this case the networks are often referred to as server and client networks respectively. The server network routing protocol. Just as in case 2, the existence of theLSP as a protocol tunnelis known only to the tunnel LSP points which are nodes inused as an H-LSP or an S-LSP as described above, but does not form an FA because the client network. Notes: a. Case 1 includes the multi-layer traffic engineering scenario where a single instanceand server networks run separate instances of the control plane routing protocol is used across both layers. This situation was particularly envisaged in [RFC4206]. b.protocols. The example citedvirtual link may be used in case 2 is special becausethe hierarchical LSP is edge-to-edge withinclient network as a particular domain and no TE links areprivate link or may be advertised outside ofin the domain (by definition ofclient network IGP. Additionally, the domain). The purpose oflink may be used in the client network to form a routing adjacency and/or as a TE link islink. 1.1.6. Link Bundles [RFC4201] recognizes that a pair of adjacent routers may have a large number of TE links that run between them. This can be a considerable burden to carry traffic acrossthe domainoperator who may need to configure them, and notto carry intra-domain traffic. Advertisingthe IGP that must distribute information about each of them. A TE link within the domain might cause internal traffic to take longer paths as it seeks to use the hierarchical LSP. c. Case 3bundle is not the only option for the multi-layer networkdefined by [RFC4201] as explained in Note a. d. The client network in case 3 may bea different technologyTE network (suchlink that is advertised as a GMPLS TDM networkan aggregate of multiple TE links that operates overcould have been advertised in their own right. All TE links that are collected into a GMPLS WDM network, or an MPLS-TE network operating overTE link bundle have the same TE properties. Thus, a GMPLS optical network),link bundle is a shorthand that improves the scaling properties of the network. Since a same-technologyTE network wherelink may, itself, be an LSP nesting is allowed (for example,(either an MPLS-TE network operating over another MPLS-TE network),FA or a non-TE network (such as an IP network operating over an MPLS-TE or GMPLS network of any technology). Thus, thevirtual link), a link advertisedbundle may be a TE link,constructed from FA-LSPs or a routing link. In the second instance, the LSP is used to form avirtual adjacency between two non-neighboring IP routers (a Routing Adjacency - RA) forming IGP shortcuts. e. IGP shortcuts are precluded when the LSP end-points reside within different IGP areas [RFC4105]. f. IGP shortcutslinks. 1.2. Desired Function It should be treated with extreme caution when they are created and used in the same IP/MPLS network. Thus, it may be more commonpossible to signal an LSP and automatically coordinate its use them as described in case 4and evenadvertisement in this case, only when the egress of the LSP is the final destinationany of the traffic carried. g. It wouldways described in Section 1.3 with minimum involvement from an operator. The mechanisms used should be unusual althoughapplicable to numbered and unnumbered links, and should not impossiblerequire implementation complexities. 1.3. Existing Mechanisms This section briefly introduces existing protocol mechanisms used to use a hierarchical LSP as an IGP shortcut withinsatisfy the control plane. 1.3. Problem Statement The extensionsdesired function described in this documentSection 1.2. 1.3.1. LSP Setup Both unidirectional LSPs and bidirectional LSPs are intended for dynamicallysignaled bi-directional Forwarding Adjacency LSPs (FA-LSPs). In particular this document addressesfrom the following points: (1) Howingress label switching router (LSR) to letthe egress node know that this bi-directional LSP needs to be advertised as an FA, or as an RA, or as an FA and RA or is a local virtual link only for the use ofLSR. That is, the ingress LSR is the initiator, and the egress nodes. (2) How to indicate that a newlearns about the LSP should be treated as part of a TE link bundlethrough the signaling protocol [RFC3209], [RFC3473]. 1.3.2. Routing Adjacency Establishment and advertised as partLink State Advertisement Although hosts can discover routers (for example through ICMP [RFC1256]), routing adjacencies are usually configured at both ends of the adjacency. This requires that bundle. (3) How to identifyeach router know the routing instance in which such an advertisement should happen. We should noteidentity of the router at the other end of the link connecting the routers, and know that these aspects are equally applicablethe IGP is to both numbered and unnumbered TE links. In orderbe run on this link. Once a routing adjacency has been established, a pair of routers may use the IGP to share information about the links available for carrying IP traffic in the egress of an LSPnetwork. Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], and IS-IS [RFC1195]. 1.3.3. TE Link Advertisement Extensions have been made to be ableIGPs to advertise the LSP as aTE link it needs to know that such an advertisement is desirable,properties ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and italso needsto know theadvertise link properties in GMPLS networks ([RFC4202], [RFC4203], and [RFC5307]). TE Router ID of the ingress LSR. (Please recall that the Router ID oflink advertisement can be performed by the other endsame instance of the linkIGP as is set in the Link-ID sub-TLV ofused for normal link state advertisement, or can use a separate instance. Furthermore, the Link TLVends of thea TE Opaque-LSA [RFC3630].) If the LSP islink advertised in an IGP do not need to form part ofa TE link bundle,routing adjacency. This is particularly the egress must also knowcase with FAs as described in Section 1.1.5. 1.3.4. Configuration and Management Techniques LSPs are usually created as the identityresult of the bundle. When the mechanism set out in section 1.1a management action. This is true even when a control plane is used for numbered FAs, there? the management action is no waya request to carrythe TE Router ID of the ingress LSR in the RSVP signaling message (Path message) and there is no waycontrol plane to indicate thatsignal the LSP. If the newLSP is to be used as an FA LSP. Therefore the egress LSR has to wait to receive a routing protocol advertisement of the TE link flooded by the ingress to learn about the new TE link andH-LSP or S-LSP, management commands can be used to deduce thatinstall the LSP forms that TEas a link. The egresslink must learn the TE Router ID of the ingress node before it can advertisebe defined, interface identifiers allocated, and the FA as described in Section 1.2. Note further, that in this approach,end points configured to know about (and advertise, if necessary) the egress LSR must search potentially many LSPs every time it receives an advertisement for anew TElink. [RFC3477] defines a different method for the exchange of information in the signaling protocol during the establishment of LSPs that will be advertised as unnumbered TE links.If the LSP_TUNNEL_INTERFACE_ID object is present, it indicates that theLSP is to be advertisedused as part of a TE link, and it containslink bundle, the TE Router IDoperator must decide which bundle it forms part of and ensure that that information is configured at the ingress LSR. This mechanism resolves many ofand egress, along with the issues listed above,necessary interface identifiers. These mechanisms are perfectly functional and provides a solution for unnumbered TE links, however,quite common in MLNs, but require configuration coordination and additional management. They are open to user error and misconfiguration that might result in the LSP_TUNNEL_INTERFACE_ID object cannot beLSP not being used for numbered FAs as currently defined, and so(a waste of resources) or the problem remains for numbered TE links. Related toLSP being made available in the above problem, a few key observations are worth noting: 6. The term FA is applicable only whenwrong way with some impact on traffic engineering. 1.3.5. Signaled Unnumbered FAs [RFC3477] describes how to establish an LSP is createdand usedto make it available automatically as a TE link in the same instance of the IGP. [RFC4206] did not consider scenarios where an LSP is created (and maintained) by one instance ofrouting protocol as advertises the IGP, and is used as a (TE) link by another instance of IGP. This leaves open the question of advertising aTE link into a different instance of the IGP as is needed in multi-region/multi-layer networks [MLN-REQ], and howlinks it traverses, using IPv4-based unnumbered identifiers to identify which instance of the IGP should be used. In addition,the new TE link advertised into the different IGP instance may be associated withlink. That is, [RFC3477] describes how to create an IGP neighbor adjacency. We call it a routing adjacency (RA).unnumbered FA. The decisionmechanism, as to whether the link should be advertised to MPLS TE topology or IP topology or both depends on operator policy. Therefore, a mechanism to indicatedefined in Section 3 of [RFC3477], is briefly as follows: - The ingress of the choice toLSP signals the Egress node is needed. 7. [RFC4206] providesLSP as normal using a way to exchange numbered identifiersPath message, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The sender's LSR Router ID - The sender's interface ID for the TE link, but this does not clearly state that the Ingress node can use presencelink being created - The egress of the LSP responds as normal to accept the LSP and set it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object as a triggeridentifies: - The egress's LSR Router ID - The egress's interface ID for the TE link advertisement atbeing created. - Following the exchange of the Path and Resv messages, both the ingress and the egress node. 8. It is important to noteknow that anthe LSP thatis set up in a server GMPLS transport network andto be advertised as a TE link in a client MPLS data network is NOT an FA-LSP according to the definitions explained in point 1, above. This isthe case regardlesssame instance of whetherthe GMPLS network is packet- or non- packet-capable. 9. When an egress checks the address ofrouting protocol as was used to advertise the advertisedTE linklinks that it traverses, and also know the unnumbered interface identifiers to finduse in the advertisement. [RFC3477] does not include mechanisms to support IPv6-based unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers. 1.3.6. Establishing Numbered FAs Through Signaling and Routing [RFC4206] describes procedures to establish an LSP sender (Recall step (4)and to make it available automatically as describeda TE link that is identified using IPv4 addresses in section 1.1), it must checkthe Link-ID addresssame instance of all received TE advertisements against its own TE Router ID. If it matches its own TE Router ID, the egress checksthe advertising router ID ofrouting protocol as advertised the TE advertisement against the ingress addresses of all LSPs for whichlinks it traverses (that is, as a numbered FA). The mechanism, as defined in [RFC4206], is the egress. It is an assertionbriefly as follows: - The ingress of the authors that this method is not scalable dueLSP signals the LSP as normal using a Path message, and sets the IPv4 tunnel sender address to the amount of processing neededIP address it will use to identify its interface for allthe TE Link State Advertisements (LSAs). 10.Further, iflink being created. This is one address from a set/31 pair. - The egress of LSPs arethe LSP responds as normal to be bundled into a single TE link [RFC4201] then not only isaccept the LSP and set it necessaryup. It infers the address that it must assign to identify toits interface for the egress thatTE link being created as the partner address of the /31 pair. - The ingress decides whether the LSP willis to be advertised as part ofa TE link,link (i.e., as an FA). If so, it is also necessary to indicateadvertises the identity oflink in the TE link. This identity is distinct fromIGP in the identity ofusual way. - If the component link. Thus, in this case an additional identifierlink is unidirectional, nothing more needs to be signaled, but none is currently available. 1.4. Current Approaches and Shortcomings [RFC3477] provides a mechanism to exchange unnumbered identifiers fordone. If the TElink during FA-LSP establishment, and this can be used as a notification tois bidirectional, the egress thatmust also advertise the LSP will be usedlink, but it does not know that advertisement is required as a TE link. So, for unnumbered TE links,there is a well-definedno indication available, and this could be documented and used as a trigger for TE linkin the signaling messages. - When the ingress's advertisement of the link is received by the egress. The use of unnumbered TE links may be arguably more sensible than assigning numbersegress it must check to FAs, especially insee whether it is the caseegress of large networks. Some operators though preferthe LSP that formed the link. Typically this means: - Check to consistently use numbered TE links for both static and dynamic (that is, FA) TE linkssee if the link advertisement is new - Check to see if the Link-ID address in their networks. Inthe case of numberedreceived advertisement matches its own TE links, however, thereRouter ID - Checks the advertising router ID from the advertisement against the ingress address of each LSPs for which it is no available indication to allowthe egress to know that an- Deduce the LSP should bethat has been advertised as a TE link. In addition, using unnumbered TE links does not address thelink and issue of advertising TE links into a different instance ofthe IGP. Therecorresponding advertisement for the reverse direction. It is no defined mechanism to identify whether it shouldpossible that some reduction in processing can be advertised as an FA,achieved by mapping based on the /31 pairing, but nevertheless, there is a full Routing Adjacency (RA), or it should be used as a local virtual link. The Link Management Protocol (LMP) [RFC4204] could possibly be run on remote adjacencies between the endpointsfair amount of an LSP. But LMP peer discovery would be required for dynamic LMP peeringprocessing required, and isthis does not currently specified. In addition, the conceptscale well in large networks. No explanation is provided in [RFC4206] of a remote LMP adjacency remains unproven. Lastly, there would be a requirementhow to create numbered IPv6 FAs. Note that all layers/regionsthis document deprecates this procedure as explained in a MLN network run LMP.Section 1.4.6. 1.4. Overview of Required Extensions This may not besection provides a brief outline of the caserequired protocol extensions. 1.4.1. Efficient Signaling of Numbered FAs The mechanism described in existing networks and would put undue burden onSection 1.3.6. is inefficient. The egress must wait until it receives an advertisement from the network operatoringress before it knows that the LSP is to deploy another protocol. 1.5. Contents of This Document This document providesbe installed as a consolidated way of exchangingTE link identifiers whenand advertised as an LSPFA. Further, it must parse all received advertisements to determine if any is established through signaling. It also provides a mechanismthe trigger for it to allowadvertise an FA. An efficient signaling mechanism is required so that the egress is informed by the ingress to control whether, and intoduring LSP establishment. 1.4.2. LSPs for Use as Private Links There is currently no mechanism by which IGP instances,an ingress can indicate that an LSP is set up for use as a private link. Any attempt to make it a link would currently cause it to be advertised as an FA and/ or RA by the egress. The proposedFA. A signaling mechanism applies equallyis needed to Hierarchical LSPs (H-LSPs) and Stitchable LSPs (S- LSPs). The method described below extendsidentify the method described in [RFC3477],use to which is applied foran FA-LSP represented asLSP is to be put. 1.4.3. Signaling an unnumbered TE link. 2. Revision history 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00 o Fixed page formatting o Updated author addresses o Readability fixes 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01 o Added indication of bundled link o Added "ACTION" field, which obsoletes R and F bits o Readability fixes 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02 o Rewrite Section 1.2 o Updated author addresses o Readability fixes 3. Proposed SolutionLSP For use in Another Network The following method allowsexisting signaling/routing mechanisms are designed for use in the ingress and egress LSRs to exchangecreation of FAs. That is, the TE link addresses or link identifiers (including the node ID) ofcreated is advertised in the ends of asingle IGP instance. The numbered or unnumberedTE link tomechanism (Section 1.3.6) could, in theory, be formed fromused in an LSP. ItMLN with multiple IGP instances if the addressing model is an extension ofkept consistent across the procedures definednetworks, and if the egress searches all advertisements in [RFC3477]all IGP instances. But this is complex and does not work for unnumbered TE links. If an ingress LSR that originates an LSP, intendsinterfaces. A signaling mechanism is required to advertise this LSP as a TE linkindicate in IS-IS or OSPF [RFC4206], the ingress LSR MUST allocate an address or identifier towhich IGP instance the TE link (just like for any other TE link), and it MUST do this before theshould be advertised. 1.4.4. Signaling an LSP setup request is signaled. Moreover, the Path message usedfor establishing the LSPUse in a Link Bundle A signaling mechanism is required to indicate that will be usedan LSP is intended to form the TEa component link MUST contain the LSP_TUNNEL_INTERFACE_ID object (as extendedof a link bundle, and described below), with the interface address or identifier allocated by the ingress LSR. If the Path message for the H-LSP/S-LSP contains the LSP_TUNNEL_INTERFACE_ID object, thento identify the egress LSR (assuming it acceptsbundle and the LSP request) MUST allocate an address or identifier toIGP instance in which the TE link that will be formed (just likebundle is advertised. 1.4.5. Support for any otherIPv4 and IPv6 The protocol mechanisms must support IPv4 and IPv6 numbered orand unnumbered TE link). Furthermore, the Resv messagelinks. 1.4.6. Backward Compatibility The existing protocol mechanisms for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the interface address or identifier allocated by the egress LSR. In all cases where an LSP isunnumbered FAs as defined in [RFC4206] and [RFC3477] must continue to be advertised as a TE link, the Tunnel Sender Addresssupported, and new mechanisms must be devised such that their introduction will not break existing implementations or deployments. Note that an informal survey in the Sender Template ObjectCCAMP working group established that there are no significant deployments of numbered FAs established using the Path message MUST betechnique described in [RFC4206] and set to the TE Router IDout in Section 1.3.6. Therefore, this document deprecates this procedure. 2. Overview of Solution This section provides an overview of the ingress LSR. We should note thatmechanisms and protocol extensions defined in this document. Details are presented in Section 3. 2.1. Common Approach for Numbered and Unnumbered Links The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is a change fromextended for use for all H-LSPs and S-LSPs whether they form numbered or unnumbered, IPv4 or IPv6 links. Different class-types of the method described in [RFC4206]. Onceobject identify the egress LSR has successfully sent a Resv message as described aboveaddress type for which it SHOULD advertise theapplies. 2.2. LSP asUsage Indication The LSP_TUNNEL_INTERFACE_ID object is given flags in a TE link using the addresses/identifiers exchanged. Once the Resv has been processed by the ingress LSR andnew Actions field to say how the LSP has been successfully established, the ingress LSR SHOULD advertise theis to be used. The following categories are supported: - LSP is used as a TE link using the addresses/identifiers exchanged. Once thean advertised TE link advertisement has been flooded it- LSP is available for use in path computation and LSP signaling just like any other TE link. 3.1. IGP Instance Identification The mechanism described so far allows an ingress LSR to indicate that anused to form a routing adjacency - LSP is to beused as ato form an advertised TE link and allows the ingress and egress LSRs to exchange addresses or identifiers for that TE link, duringa routing adjacency - LSP setup. However, itforms a private link and is also necessarynot advertised 2.3. IGP Instance Identification An optional TLV is added to indicatethe LSP_TUNNEL_INTERFACE_ID object to identify the IGP instance into which instance ofthe IGPlink formed by the advertisement shouldLSP is to be made. Thisadvertised. If the TLV is only necessary ifabsent and the LSPlink is to be advertised as a TE link into a different instance of the IGP, andindicated by the default behavior may safely be left withActions field, the LSPlink is advertised intoin the same instance of the IGP. Indication of theIGP in whichas was used to advertise the advertisementTE links it traverses. 2.4. Link Bundle Identification When an LSP is to be made first requires that a 32-bit identifier be assigned to each of the IGP instances withinused as a network, and that ingress and egress LSRs have the same understandingcomponent link of these numbers. This isa management configuration exercise outside the scope of this document. Once these numbers have been assigned, they MAY be signaled as additional information inlink bundle, the LSP_TUNNEL_INTERFACE_ID object refers to indicate to which instance ofthe IGPbundle indicating how the object applies. The IGP instance identifier value of 0xffffffffbundle is reserved to indicate thataddressed and used, and a new TLV indicates the TEcomponent link SHOULD be advertised into the same instance of the IGP as was used to establish the LSP. Similarly, absence of the IGP instanceidentifier meansfor the link that an FA is to be established (inthe same IGP instance). 3.2.LSP advertisementcreates. 2.5. Backward Compatibility Backward compatibility has three aspects. - Existing mechanisms for unnumbered FAs described in [RFC3477] and Usage Identification As mentioned earlier, the egress node also needs[RFC4206] must continue to know if it needswork, so that ingress nodes do not have to create a full routing adjacency or forwarding adjacency or just needbe updated when egresses are updated. - Existing mechanisms for establishing numbered FAs described in [RFC4206] are safely deprecated by this document as they are not significantly deployed. - New mechanisms must be gracefully rejected by existing egress implementations so that egress nodes do not have to be updated when ingresses are updated. 3. Mechanisms and Protocol Extensions This section defines protocol mechanisms and extensions to treatachieve the LSP as a local virtual link.function described in the previous section. 3.1. LSP_TUNNEL_INTERFACE_ID Object The extensionsprincipal signaling protocol element used to achieve all of the required functions is the LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. The existing definition and usage continues to be supported as described in the following also specifynext section. Subsequent sections describe new variants of the LSP advertisementobject (denoted by new Class Types), and usage treatment. It is not mutually exclusive whetheradditional information carried in the LSP has routing adjacencyobject by means of extensions. 3.1.1. Existing Definition and whether it has forwarding adjacency. The LSP can have both routingUsage This document does not deprecate the mechanisms defined in [RFC3477] and forwarding adjacency. In this case,[RFC4206]. Those procedures must continue to operate as described in Section 3.7. That means that the LSPLSP_TUNNEL_INTERFACE_ID object with Class Type 1 remains unchanged, and can be used to carry both pure IP datagram packets and MPLS labeled packets. If theestablish an LSP has only forwarding adjacency, it is usedthat will be advertised as an unnumbered TE link in the same instance of the IGP as TE-linkwas used to carry only MPLS labeled packets. Ifadvertise the LSP has only routing adjacency, it is used as IP link to carry only pure IP datagram packets. NoteTE links that the LSP which has only forwarding adjacencytraverses. That is, as an FA. The procedure is useful to improve the scalability. Suppose that distant PSC domains are connected by a set of lower-layer LSPs createdunchanged and operates as summarized in the optical domain (TDM, LSC, or FSC). We doSection 1.3.5. [RFC3477] does not require routing adjacency on all such lower-layer LSPs as long as we have control plane connectivity through a subset of lower-layer LSPs which have routing adjacency. We reducemake any suggestions about where in Path or Resv messages the amountLSP_TUNNEL_INTERFACE_ID object should be placed. See Section 3.5 for recommended placement of overheadthis object in new implementations. 3.1.2. Unnumbered Links with Action Identification A new C-Type variant of IGP protocol processing on the LSPs which do not have routing adjacency. It is mutually exclusive whether the LPS has routing adjacency and whether it is treated as a local virtual link. Likewise, it is mutually exclusive whetherthe LSP has forwarding adjacency and whether it is treated as a local virtual link. 3.3. Bundling It is possible to treat LSPs as component links and to bundle them into a single TE link. However thereLSP_TUNNEL_INTERFACE_ID object is currently no waydefined to signal thatcarry an LSP will be used as part of a bundleunnumbered interface identifier and to identify the bundled link toindicate into which instance of the LSP is supposed to belong. Each LSP that is to form a component link is signaled using the LSP_TUNNEL_INTERFACE_ID object to identifyIGP the consequent TE link bundle to which the LSP will belong. Thus multiple LSPs mayshould be signaled with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID object. Whenadvertised. This does not deprecate the LSP is to form a component link,use of C-Type 1. The format of the LSP_TUNNEL_INTERFACE_IDobject is as shown below. C-NUM = 193, C-Type = 4 (TBD by IANA) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR's Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Actions | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSR's Router ID Unchanged from the definition in [RFC3477]. Interface ID Unchanged from the definition in [RFC3477]. Actions This field specifies how the LSP that is being set up is to be treated. The field has meaning only on a Path message. On a Resv message the field SHOULD be set to reflect the value received on the corresponding Path message, and MUST also contain an additional TLVbe ignored on receipt. The field is composed of bit flags as follows: -+-+-+-+-+-+-+- | | | |H|B|R|T|P| -+-+-+-+-+-+-+- P-flag (Private) 0 means that the LSP is to be advertised as a link according to identifythe componentsettings of the other flags. 1 means the LSP is to form a private link and is not to be advertised in the IGP, but is to be used according to the settings of the other flags. T-flag (TE link) 0 means that the LSP is to be used as a TE link. This may1 means that the LSP is not to be used as a numbered or unnumbered identifier. Multiple LSPsTE link. It may still be signaled withused as an IP link providing a routing adjacency as defined by the same address/identifier inR-flag. R-flag (routing adjacency) 0 means that the LSP_TUNNEL_INTERFACE_ID object. 3.4. LSP_TUNNEL_INTERFACE_ID Object The LSP_TUNNEL_INTERFACE_IDlink is not to be used as a routing adjacency. 1 means that the link is to be used to form a routing adjacency. B-flag (bundle) 0 means that the LSP will not form part of a link bundle. 1 means that the LSP will form part of a bundle. See Section 3.3 for more details. H-flag (hierarchy/stitching) The use of an LSP as an H-LSP or as an S-LSP is usually implicit from the network technologies of the networks and the LSP, but this is not always the case (for example, in PSC networks). 0 means LSP to be used as a hierarchical LSP. 1 means LSP to be used as a stitching segment. Other bits are reserved for future use. They MUST be set to zero on transmission and SHOULD be ignored on receipt. Note that all defined bit flags have meaning at the same time. An LSP that is to form an FA would carry the Actions field set to 0x00. That is: P=0 (advertised) T=0 (TE link) R=0 (not a routing adjacency) B=0 (not a bundle) H=0 (hierarchical LSP) Reserved The Reserved bits MUST be set to zero on transmission and SHOULD be ignored on receipt. TLVs Zero, one, or more TLVs may be present. Each TLV is encoded as follows: Type (16 bits) The identifier of the TLV. Two type values are defined in this document: 1 IGP Instance Identifier TLV 2 Component Link Identifier TLV Length (16 bits) Indicates the total length of the TLV in octets. I.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned. Value The data for the TLV padded as described above. If this object is carried in a Path message it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message the object is known as the "Reverse Interface ID" for the LSP. 3.1.3. IPv4 Numbered Links with Action Identification A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an IPv4 numbered interface address. The format of the object is as shown below. C-NUM = 193, C-Type = 2 (TBD by IANA) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Actions | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Interface Address The address assigned to the interface the sender applies to this LSP. Actions See Section 3.1.2. Reserved See Section 3.1.2. TLVs See Section 3.1.2. If this object is carried in a Path message it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message the object is known as the "Reverse Interface ID" for the LSP. 3.1.4. IPv6 Numbered Links with Action Identification A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an IPv6 numbered interface address. The format of the object is as shown below. C-NUM = 193, C-Type = 3 (TBD by IANA) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Actions | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Interface Address The address assigned to the interface the sender applies to this LSP. Actions See Section 3.1.2. Reserved See Section 3.1.2. TLVs See Section 3.1.2. If this object definedis carried in [RFC3477] hasa class number of 193, which designatesPath message it is known as the "Forward Interface ID" for the LSP that is being set up. On a node that does not understand the object SHOULD ignoreResv message the object but forward it, unexamined and unmodified, in all messages resulting from this message. [RFC3477] defines one class type to indicate an unnumbered interface identifier. This document defines three new class typesis known as follows. C-Type Meaning Reference ---------------------------------------------------------------- 1 Unnumbered interface identifier [RFC3477] 2 (TBD by IANA) IPv4 interface identifier with target 2.2.2 3 (TBD by IANA) IPv6 interface identifier with target 2.2.3 4 (TBD by IANA) Unnumbered interface with target 2.2.4 Multiple instances ofthe LSP_TUNNEL_INTERFACE_ID object with C- Type values 2, 3 or 4 MAY appear in any one Path or Resv message, in which case, each MUST have a different value"Reverse Interface ID" for the LSP. 3.2. Target IGP Instance field. A Path or Resv message MUST NOT contain more than oneIdentification TLV If the LSP being set up is to be advertised as a link, the egress needs to know which instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1,IGP it should use to make the advertisement. The default in [RFC4206] and if such an object[RFC3477] is present, other instancesthat the LSP is advertised as an FA, that is, in the same instance of the object with any other C-Type value MUST NOT have TargetIGP Instance setas was used to 0xffffffff. 3.4.1. Unnumbered link The unnumbered link identifier defined by [RFC3477]advertise the TE links that the LSP traverses. In order to facilitate an indication from the ingress to the egress of which IGP instance to use, the IGP Identification TLV is not changed bydefined for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID object defined in this document. Its usage also remains the same. That is, when presentThe TLV has meaning only in a Path message it indicates that the LSP being establishedmessage. It SHOULD NOT be advertised byincluded in the egress LSR asLSP_TUNNEL_INTERFACE_ID object in a TE link,Resv message and that unnumbered link identifier isMUST be ignored if found. If the ingress' identifier forP-flag in the TE link. Note that since this formActions field of the LSP_TUNNEL_INTERFACE_ID object does not contain a target IGP instance identifier it cannot identifyin a specific instance ofPath message is clear (i.e., zero), this TLV indicates the IGP into which this TE link should be advertised. Similarly, LSP advertisement and usage treatment also needsinstance to be specified. Thus, when C-Type 1 is used,use for the TE link SHOULD be advertised only intoadvertisement. If the TLV is absent, the same instance of the IGP should be used as wasis used to createadvertise the LSP. That is,TE links that the use of C-Type 1 is unchanged from [RFC3477] and is used to createLSP traverses. Thus, for an unnumbered Forwarding Adjacency. This objectFA, the TLV can appear in either a Path messagebe omitted; alternatively, the IGP Instance TLV may be present identifying the IGP instance or a Resv message. Incarrying the former case, we call itreserved value 0xffffffff. If the "Forward Interface ID" for that LSP;P-flag in the latter case, we call it the "Reverse Interface ID" forActions field in the LSP. A Path orLSP_TUNNEL_INTERFACE_ID object in a Resv message MUST have only one instance of this object with C-Type 1. 3.4.2. IPv4 numbered link A new C-Type variant ofis set (i.e., one) indicating that the LSP_TUNNEL_INTERFACE_ID ObjectLSP is definednot to carry an IPv4 numbered interface addressbe advertised as a link, this TLV SHOULD NOT be present and to indicate into which instance of the IGP the consequent TE link shouldMUST be advertised.ignored if encountered. The format of the objectTLV is formatted as shown below. C-NUM = 193, C-Type = 2(TBD by IANA)described in Section 3.1.2. The Type field has the value 1, and the Value field has the following content: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Interface Address (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetIGP Instance (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVsIdentifier | ~ ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACTION: This field specifies howIGP Instance Identifier A 32-bit identifier be assigned to each of the LSP advertisementIGP instances within a network, such that ingress and usage treatment. It indicates if theegress LSR needs to createLSRs have the same understanding of these numbers. This is a full routing adjacency or forwarding adjacencymanagement configuration exercise outside the scope of this document. Note that the IGP Instance Identifier might be mapped from an instance identifier used in the IGP itself (such as section 2.4 of [RFC5340] for OSPFv3, or just need[OSPFv2-MI] for OSPFv2) as a matter of network policy. See [OSPF-TI] for further discussion of this topic in OSPF, and [ISIS-GENAP] for IS-IS. The value 0xffffffff is reserved to treatmean that the LSP is to be advertised in the same instance of the IGP as a local virtual link. It takeswas used to advertise the TE links that the LSP traverses. 3.3. Component Link Identification TLV If the following values: "0000":LSP that is being set up is to be used as a component link in a link bundle [RFC4201], it is necessary to indicate both the identity of the component link and the identity of the link bundle. Furthermore, it is necessary to indicate how the link bundle (that may be automatically created by the establishment of this LSP) is an FAto be used and is only advertised intoadvertised. If the MPLS-TE topology. We should note that it assuresB-flag in the backward compatibility withActions field of the method to exchange unnumbered FA information described in [RFC3477]. "0001": LSP is an RA andLSP_TUNNEL_INTERFACE_ID object is only advertised intoset, the IP network. "0010": LSP is an RA and FAother fields of the object apply to the link bundle itself. That is, the interface identifiers (numbered or unnumbered) and is advertisedthe other flags in both IPthe Actions field apply to the link bundle and MPLS-TE topologies. "0011":not to the component link that the LSP is neitherwill form. Furthermore, the FA nor RAIGP Instance Identifier TLV (if present) also applies to the link bundle and isnot to be used as a local virtualthe component link. In this caseorder to exchange the LSP is advertised neither in IP nor MPLS topology. The Padding MUST beidentity of the component link, the Component Link Identifier TLVs are introduced as set to zero on transmission, SHOULD be ignored and forwarded unchanged, and SHOULD be ignored on receipt. This object can appearout in either a Path message or a Resv message. Inthe former case, we call itnext sections. If the "Forward Interface Address" for that LSP;B-flag is set in the latter case, we call itActions field of the "Reverse Interface Address" forLSP_TUNNEL_INTERFACE_ID object in the LSP. 3.4.3. IPv6 numbered link A new C-Type variantPath message, exactly one of these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID Object is defined to carry an IPv6 numbered interface addressobject in both the Path and Resv objects. 3.3.1. Unnumbered Component Link Identification If the component link is to indicate into which instance ofbe unnumbered, the IGPUnnumbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 2, and the consequent TE link should be advertised. The format ofValue field has the object is as shown below. C-NUM = 193, C-Type = 3(TBD by IANA)following content: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IGP Instance (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVsComponent Link Identifier | ~ ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. In the former case, we call it the "Forward Interface Address" for that LSP; in the latter case, we call it the "Reverse Interface Address" for the LSP. 3.4.4.Component Link Identifier Unnumbered link with target IGP instanceidentifier A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Objectthat is defined to carry an unnumbered interface identifier andassigned to indicate into which instance ofthis component link within the IGPbundle [RFC4201]. 3.3.2. IPv4 Numbered Component Link Identification If the consequent TEcomponent link should be advertised. This does not deprecateis identified with an IPv4 address, the use of C-Type 1, but extends its utility.IPv4 Numbered Component Link Identifier TLV is used. The format of the objectTLV is formatted as shown below. C-NUM = 193, C-Type = 4(TBD by IANA)described in Section 3.1.2. The Type field has the value 3, and the Value field has the following content: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR's Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IGP Instance (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. In the former case, we call it the "Forward Interface ID" forIPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Address The IPv4 address that LSP; in the latter case, we call it the "Reverse Interface ID" foris assigned to this component link within the LSP. 3.4.5. Message Formats [RFC3477] does not state where inbundle. 3.3.2. IPv6 Numbered Component Link Identification If the Path message or Resv messagecomponent link is identified with an IPv6 address, the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209] states that all implementations are to handle all objects received in any order, thisIPv6 Numbered Component Link Identifier TLV is not a problem. However, itused. The TLV is RECOMMENDED that the LSP_TUNNEL_INTERFACE_ID object(s) be placedformatted as described in Section 3.1.2. The Type field has the Path message immediately after the SENDER_TSPEC object,value 4, and in the Resv message immediately after the FILTER_SPEC object. 3.5. TLVs All TLVs ofthe LSP_TUNNEL_INTERFACE_ID object haveValue field has the following format.content: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (16 bits)IPv6 Address | Length (16 bits)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable)IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | ~ ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address The length field containsIPv6 address that is assigned to this component link within the total lengthbundle. 3.4. Link State Advertisement The ingress and egress of an LSP that is set up using the LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in the parameters of the object. Where a TE link is created from the LSP, the TE link SHOULD inherit the TE properties of the LSP as described in [RFC5212] but this process is subject to local and network-wide policy. It is possible that an LSP will be used to offer capacity and connectivity to multiple other networks. In this case, multiple instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the same Path and Resv messages. Each instance MUST have a different IGP Instance Identifier. Note, however, that a Path or Resv message MUST NOT contain more than one instance of the TLV including the TypeLSP_TUNNEL_INTERFACE_ID object with C-Type 1, and Length fields in bytes A value field whose lengthif such an object is not a multiplepresent, all other instances of fourthe LSP_TUNNEL_INTERFACE_ID object MUST be zero-padded soinclude an IGP Instance Identifier TLV with IGP Instance Identifier set to a value that identifies some other IGP instance (in particular, not the TLVvalue 0xffffffff). If the link created from an LSP is four-byte aligned. This document defines two Type values to beadvertised in the same IGP instance as was used to specifyadvertise the component link identifierTE links that the sending LSR has assigned to theLSP iftraverses, the addresses for the new link and that for the links it forms part of a TEis built from MUST come from the same address space. If the link bundle. The consequent TLV formats are shownis advertised into another IGP instance the addresses MAY be drawn from overlapping address spaces such that some addresses have different meanings in each IGP instance. In the next sections. 3.5.1. Unnumbered Component Link Identifier 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Link Identifier (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLVIGP the TE Router ID of the ingress LSR is present iftaken from the Tunnel Sender Address in the Sender Template object signaled in the Path message. It is assumed that the ingress LSR knows the signaledTE Router ID of the egress LSR since it has chosen to establish an LSP isto be usedthat LSR and plans to use the LSP as an unnumbered component link ofa bundledTE link. In this case, the identifier (numberedThe link interface addresses or unnumbered) inlink interface identifiers for the main body offorward and reverse direction links are taken from the LSP_TUNNEL_INTERFACE_IDLSP_TUNNEL_INTREFACE_ID object indicateson the TE link bundle of which thisPath and Resv messages respectively. When an LSP is torn down through explicit action (a PathTear message or a component,PathErr message with the Path_State_Removed flag set) the ingress and egress LSRs SHOULD withdraw the Component Link Identifieradvertisement of this TLV specifiesany link that the unnumbered identifierLSP created and that was previously advertised. The link state advertisement MAY be retained as a virtual link in another layer network according to network-wide policy [PCE-LAYER]. 3.5. Message Formats [RFC3477] does not state where in the Path message or Resv message the LSP_TUNNEL_INTERFACE_ID object should be placed. It is assignedRECOMMENDED that new implementations place the LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after the SENDER_TSPEC object, and in the Resv message immediately after the FILTER_SPEC object. All implementations SHOULD be able to this component link withinhandle received messages with objects in any order as described in [RFC3209]. 3.6. Error Cases and Non-Acceptance Error cases and non-acceptance of new object variants caused by back- level implementations are discussed in Section 3.7. An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may have cause to reject the parameters carried in the object for a number of reasons as set out below. In all cases, the egress SHOULD respond with a PathErr message with the error code as indicated in the list below. In most cases the error will arise during LSP setup, no Resv state will exist, and the PathErr will cause Path state to be removed. Where the bundle. This TLV MUST NOTerror arises after the LSP has been successfully set up, the PathErr SHOULD be present insent with the same instance ofPath_State_Removed flag [RFC3473] clear so that the LSP_TUNNEL_INTERFACE_ID objectLSP remains operational. The error cases identified are as a TLV with type 2 (numbered component link identifier). 3.5.2. IPv4 Numbered Component Link Identifier 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0follows and are reported using the new error code 'LSP Hierarchy Issue' (code 34 TBD by IANA) and the error values listed below. Error | Error | Error-case code | value | ------+-------+------------------------------------------------------ 34 1 Link advertisement not supported 34 2 Link advertisement not allowed by policy 34 3 TE link creation not supported 34 4 TE link creation not allowed by policy 34 5 Routing adjacency creation not supported 34 6 Routing adjacency creation not allowed by policy 34 7 Bundle creation not supported 34 8 Bundle creation not allowed by policy 34 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV is present if the signaledHierarchical LSP is to be used as a numberednot supported 34 10 LSP stitching not supported 34 11 Link address type or family not supported 34 12 IGP instance unknown 34 13 IGP instance advertisement not allowed by policy 34 14 Component link identifier not valid 34 15 Unsupported component link ofidentifier address family When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a bundled TE link. In this case,Resv message it may need to reject it because of the identifier (numbered or unnumbered)setting of certain parameters in the main body ofobject. Since these reasons all represent errors rather than negotiable parameter-mismatches, the LSP_TUNNEL_INTERFACE_ID object indicatesingress SHOULD respond with a PathTear to remove the TE link bundleLSP. The ingress MAY use a ResvErr with one of which thisthe following error codes, allowing the egress the option to correct the error in a new Resv message, or to tear the LSP iswith a component, and the IPv4 Address field of this TLV specifies the numbered identifierPathErr with Path_State_Removed flag set. An ingress that is assigned to this component link withinuses the bundle. This TLVResvErr MUST NOT be present intake precautions against a protocol loop where the same instance ofegress responds with the same LSP_TUNNEL_INTERFACE_ID object as a TLVwith the same or different) issues. Error | Error | Error-case code | value | ------+-------+------------------------------------------------------ 34 11 Link address type 1 (unnumberedor family not supported 34 14 Component link identifier not valid 34 15 Unsupported component link identifier). 3.6. LSA advertisement The ingress and egress LSRs MAY advertiseidentifier address family 34 16 Component link state associated with TE links created as described above.identifier missing 3.7. Backward Compatibility The link state may be advertisedLSP_TUNNEL_INTERFACE_ID object defined in either the same IGP instance as used[RFC3477] has a class number of 193. According to compute and signal the path for the LSPs[RFC2205], this means that supporta node that does not understand the TE links, or another IGP instance. Inobject SHOULD ignore the former case,object but forward it, unexamined and unmodified. Thus there are no issues with transit LSRs supporting the address space forpre-existing or new Class Types of this object. A back-level ingress node will behave as follows: - It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID objects with the link state MUST benew Class Types defined in this document. - It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID objects with the samenew Class Types defined in this document as that used to establish the LSPs.described in [RFC2205]. In the latterany case, the address space for the link state MAY be different, which means that addresses already allocated in the IGP instance used to establish the LSPs MAY be usedsuch a situation would represent an error by the advertised TE link without any ambiguity. In the IGP the TE Router ID of the ingress LSR is taken fromegress. - It will continue to use the Tunnel Sender AddressLSP_TUNNEL_INTERFACE_ID object with Class Type 1 as defined in [RFC3477]. This behavior is supported by back-level egresses and by egresses conforming to this document. - According to an informal survey, there is no significant deployment of numbered FA establishment following the Sender Template object.procedures defined in [RFC4206] and set out in Section 1.3.6 of this document. It is assumedtherefore safe to assume that theback-level ingress LSR knows the TE Router ID of theLSRs will not use this mechanism. A back-level egress LSR since it has chosen to establish an LSP to that LSR and plansnode will behave as follows: - It will continue to usesupport the LSPLSP_TUNNEL_INTERFACE_ID object with Class Type 1 as defined in [RFC3477] if issued by an ingress. - It will reject a TE link. The link interface addresses or link interface identifiers forPath message that carries an LSP_TUNNEL_INTERFACE_ID object with any of the forward and reverse direction links are taken fromnew Class Types defined in this document using the LSP_TUNNEL_INTREFACE_ID object onprocedures of [RFC2205]. This will inform the Path and Resv messages respectively. Address overlap checking for these objects MUST be turned off wheningress that the LSAegress is advertised intoa IGP instance different from the one usedback-level LSR. - It will not expect to establish the LSP becauseuse the addresses MAY be allocated in both domains. 4. Applicability Statement The method is applicableprocedures for both hierarchical LSPsnumbered FA establishment defined in [RFC4206] and LSP stitching [STITCH]. 5. Backward Compatibility Considerations The method doesset out in Section 1.3.6 of this document. In summary, the new mechanisms defined in this document do not impact the method to exchange unnumbered FA information described in [RFC3477]. That mechanism can be safely used in combination with the new mechanisms described here and is functionally equivalent to using the new C-Type indicating an unnumbered link with target IGP instance identifier with the Target IGP Instance value set to 0xffffffff. This method obsoletes the method to exchange the numbered FA information described in [RFC4206]. This is not believed to be an issue as an informal survey indicated that dynamically signaled numbered FAs had not been deployed. Indeed it wasThe mechanisms in this document obsolete the attempt to implement numbered FAs that gave risemethod to exchange the work on this document. 6.numbered FA information described in [RFC4206] as described in Section 1.4.6. 4. Security Considerations [RFC3477] points out that one can argue that the use of the extra interface identifier that it provides could make an RSVP message harder to spoof. In that respect, the minor extensions to the protocol made in this document do not constitute an additional security risk, but could also be said to improve security. It should be noted that the ability of an ingress LSR to request that an egress LSR advertise an LSP as a TE link MUST be subject to appropriate policy checks at the egress LSR. That is, the egress LSR MUST NOT automatically accept the word of the ingress unless it is configured with such a policy. 7.Further details of security for MPLS-TE and GMPLS can be found in [GMPLS-SEC]. 5. IANA Considerations This document defines three new C-Types5.1. New Class Types IANA maintains a registry of RSVP parameters called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Class Names, Class Numbers, and Class Types." There is an entry in this registry for the LSP_TUNNEL_INTERFACE_ID object. The C-Typesobject defined in [RFC3477] with one Class Type defined. IANA is requested to allocate three new Class Types for this object are managed by IANA,as defined in Sections 3.1.2, 3.1.3, and 3.1.4 as follows: C-Type Meaning Reference --------------------------------------------------------------- 2 IPv4 interface identifier with target [This.doc] 3 IPv6 interface identifier with target [This.doc] 4 Unnumbered interface with target [This.doc] 5.2. Hierarchy Actions Section 3.1.2 defines an 8-bit flags field in the LSP_TUNNEL_INTERFACE_ID object. IANA is requested to assigncreate a new sub-registry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry called the "Hierarchy Actions" sub-registry as follows: Registry Name: Hierarchy Actions Reference: [This.doc] Registration Procedures: IETF Standards Action RFC Registry: Bit Number Hex Value Name Reference ---------- ----------- ----------------------- --------- 0-2 Unassigned 3 0x10 Hierarchy/stitching (H) [This.doc] 4 0x08 Bundle (B) [This.doc] 5 0x04 Routing adjacency(R) [This.doc] 6 0x02 TE link (T) [This.doc] 7 0x01 Private (P) [This.doc] 5.3. New Error Codes and Error Values IANA maintains a registry of RSVP error codes and error values toas the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry. IANA is requested to define a new C-Typeserror code with suggested value 34 as tabulated in section 2.2 and described in sections 2.2.2, 2.2.3 and 2.2.4. 8. Acknowledgementbelow (see also Section 3.6). Error Code Meaning 34 LSP Hierarchy Issue [This.doc] IANA is requested to list the following error values for this error code (see also Section 3.6). This Error Code has the following globally-defined Error Value sub-codes: 1 = Link advertisement not supported [This.doc] 2 = Link advertisement not allowed by policy [This.doc] 3 = TE link creation not supported [This.doc] 4 = TE link creation not allowed by policy [This.doc] 5 = Routing adjacency creation not supported [This.doc] 6 = Routing adjacency creation not allowed by policy [This.doc] 7 = Bundle creation not supported [This.doc] 8 = Bundle creation not allowed by policy [This.doc] 9 = Hierarchical LSP not supported [This.doc] 10 = LSP stitching not supported [This.doc] 11 = Link address type or family not supported [This.doc] 12 = IGP instance unknown [This.doc] 13 = IGP instance advertisement not allowed by policy [This.doc] 14 = Component link identifier not valid [This.doc] 15 = Unsupported component link identifier address [This.doc] family 16 = Component link identifier missing [This.doc] 6. Acknowledgements The authors would like to thank John Drake andDrake, Yakov RekhterRekhter, and Igor Bryskin for their valuable discussions and comments. Funding for the RFC Editor function is currently provided by the Internet Society. 9.7. References 18.104.22.168. Normative References [RFC2119]Bradner,[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209]Awduche,[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3477]Kompella,[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) Signaling Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC4201]Kompella,[RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005. [STITCH][RFC5150] Ayyangar, A. and J.P.A., Vasseur, J.P, and Farrel, A., "Label Switched Path Stitching with Generalized MPLSMultiprotocol Label Switching Traffic Engineering", draft-ietf-ccamp-lsp-stitching, (work in progress). 9.2.Engineering (GMPLS TE)", RFC 5150, February 2008. 7.2. Informative References [RFC3630]Katz,[RFC1195] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4105]Le Roux, J.-L., Vassuer, J.-P., and Boyle, J. (Eds.), "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4204]Lang, J. (Ed.), "Link Management Protocol (LMP)",[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4204,4202, October 2005. [RFC4726]Farrel, A., Vasseur, J.-P.,[RFC4203] Kompella, K. Ed. and Ayyangar, A., " A Framework for Inter-Domain MultiprotocolY. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching Traffic Engineering ",(GMPLS)", RFC 4726, November 2006. [MLN-REQ]Shiomoto,4203, October 2005. [RFC5212] Shiomoto, K., et al, "Requirements for GMPLS-based multi-regionGMPLS-Based Multi- Region and multi-layer networksMulti-Layer Networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-reqs, (workRFC 5212, July 2008 [RFC5305] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 5305, October 2008. [RFC5307] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in progress). [PCE-INTER-LAYER-REQ]Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. [RFC5329] Ishiguro, K., Manral, V., Davey, A., and Lindem, A., (Ed.), "Traffic Engineering Extensions to OSPF version 3", RFC 5329, September 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [GMPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security- framework, work in progress. [ISIS-GENAP] Ginsberg, L., Previdi, S., and Shand, M., "Advertising Generic Information in IS-IS", draft-ietf-isis-genapp, work in progress. [ISIS-IPV6-TE] Harrison, J., Berger, J., and Bartlett, M., "IPv6 Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, work in progress. [OSPF-TI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Transport Instance Extensions", draft-acee-ospf-transport-instance, work in progress. [OSPFv2-MI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Multi- Instance Extensions", draft-acee-ospf-multi-instance, work in progress. [PCE-LAYER] Oki, E. (Ed.), " PCC-PCE"PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering ", draft-ietf-pce-inter-layer-req,Engineering", draft- ietf-pce-inter-layer-req, (work in progress). Author's8. Editors' Addresses Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 4402 Email: firstname.lastname@example.org Adrian Farrel Old Dog Consulting EMail: email@example.com 9. Authors' Addresses Richard Rabbat Google Inc. 1600 Amphitheatre Pkwy Mountain View, CA 94043 Email: firstname.lastname@example.org Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America Phone:Email: email@example.com Adrian Farrel Old Dog Consulting EMail: firstname.lastname@example.orgZafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada. EMail: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org@ietf.org. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.