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 (Old                  Old Dog Consulting)
                                           Z. Ali (Cisco Systems, Inc.)
    Expires: August Consulting
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.txt

                    draft-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-
       Drafts Internet-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 Generalized

   Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
   (MPLS) or Generalized MPLS (GMPLS) Label
       Switched Paths (LSPs).  It describes networks can be used to form links
   for carrying traffic in those networks or in other (client) networks.

   Protocol extensions already exist to allow facilitate the establishment of
   an
       egress to identify that a bi-directional LSP will be used as a
       dynamically signaled Forwarding Adjacency LSP (FA-LSP) or numbered traffic engineering (TE) link within the same
   instance of the routing as is used to advertise the links that it
   traverses creating a
       Routing Forwarding Adjacency (RA). In addition, the (FA). This document extends
   those mechanisms to support unnumbered FAs.

   This document also discusses
       the issue of defines how to indicate that an LSP should be
   advertised as a traffic engineering (TE) link into a different in 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 how to 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..........................3 Statement ............................. 1
   1.1. Background ...................................................
   1.1.1. Hierarchical LSPs ..........................................
   1.1.2. LSP Hierarchy............................................3 Stitching 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...............................4 Desired Function .............................................
   1.3. Problem Statement........................................6
    1.4. Current Approaches Existing Mechanisms ..........................................
   1.3.1. LSP Setup ..................................................
   1.3.2. Routing Adjacency Establishment and Shortcomings.......................8
    1.5. Contents Link 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.................................9 Required 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...........................................9 Overview of Solution ...........................................
   2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9 Common Approach for Numbered and Unnumbered Links ............
   2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9 LSP 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 advertisement Identification ..................................
   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 link Numbered Links with target Action 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. IPv4 Identification ...................
   3.3.2. Numbered Component Link Identifier.................18 Identification .....................

   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...........................................23 References .......................................
   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 of set up Label Switched Paths (LSPs) in
   Generalized Multi-Protocol Multiprotocol Label Switching (GMPLS) by allowing Traffic 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 within collect together TE links between the same instance
   pair of the
       control plane nodes and advertise them as was used to set up the LSP. This a single TE link is called a Forwarding Adjacency (FA), link
   bundle.

   [RFC5212] presents a framework and the LSP is known as an
       FA-LSP.

       [RFC4206] defines the operation as follows requirements for a numbered FA:

       1. The ingress signals multilayer
   networks (MLNs). This includes the establishment of an LSP using in a /31 sender address
   server network that it
          allocates is used as the source address a link in the signaling message
          (tunnel sender address a 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 ID made available for use
   as H-LSPs or as components of the egress
          (destination address a link bundle and advertised
   appropriately in an interior gateway protocol (IGP). These issues
   relate to coordinating between the Sender object of LSP's end points the Path
          message).

       2. The egress sets up use to which
   the LSP using normal procedures and
          allocating the partner address of the assigned /31 address in is 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 using the routing protocol (OSPF/ISIS) mechanisms that already exist, and  using
   enumerates the /31 address protocols extensions and mechanisms that are needed.
   The document goes on to
          identify the local end of the TE link.

       4. When the egress receives present the TE link advertisement, it checks necessary additions to the Link-ID address GMPLS
   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 ID H-LSPs is formalized in [RFC4206]
   with a set of protocol mechanisms for the TE advertisement
          against the ingress addresses establishment of all an 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 it only
   according to their switching types. This is a function of the
          egress and finds way
   labels are carried. In a packet switch capable (PSC) network, the address match with
   H-LSP can carry other PSC LSPs using the advertising router
          ID of MPLS label stack. In non-
   packet networks where the TE advertisement.

       5. The egress then advertises label is implicit, label stacks are not
   possible and rely on the FA ability 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 ID single hop in the Link-ID and the partner
          address path 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 that LSP can be
       achieved carried by using the 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 an Stitching 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 can same
   switching type to be used either included (stitched) as a link inside or outside
       the network that was used to form the hops in an end-to-end
   LSP. In the former case,
       the The 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
       link in a client network. The former case can only be achieved the control plane in packet networks the
   same way as they are an H-LSP, but in the only type of network data plane the LSPs are stitched so
   that
       supports there is no label stacking or nesting of LSPs within technologies. Thus, an
   S-LSP must be of the same switching technology LSP, but the
       latter case is applicable to all client/server network
       relationships such as IP over MPLS, or packet over optical.

       Second, the link formed by the 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 kept used as a private link link. Such links are known only
   by 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 rise end-points, but are not usually used to four possible combinations as
       follows.

       1. The LSP
   carry traffic that is created and advertised as a TE link in going beyond the same
       instance egress 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 no LSP.

1.1.4. Routing Adjacencies

   A routing adjacency is formed
       over between 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 LSP tunnel is created and made also usually
   available to carry for 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 as instance of the links
   control plane that it traverses, but it is not
       advertised. The availability of advertises the LSP is private to TE links from which the end
       points. This LSP 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, but called an FA-LSP.

   Thus, an H-LSP or S-LSP may form an FA such that it is advertised as
   a TE link in
       another the same instance of the routing protocol. This method of
       operation is particular protocol 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 can may be created in one network and used by as a client network without
       being advertised link (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 the LSP as a protocol tunnel is
       known only to the tunnel LSP points which are nodes in used 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 instance and 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 cited virtual link may be used in case 2 is special because the
       hierarchical LSP is edge-to-edge within client network as a particular domain and
       no TE links are private link
   or may be advertised outside of in the domain (by definition
       of client network IGP. Additionally, the domain). The purpose of
   link may be used in the client network to form a routing adjacency
   and/or as a TE link is link.

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
       across the domain operator who may need to configure them, and not to carry intra-domain traffic.
       Advertising the 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 3 bundle
   is not the only option for the multi-layer network defined by [RFC4201] as
       explained in Note a.

       d. The client network in case 3 may be a different technology TE
       network (such link that is advertised as a GMPLS TDM network an
   aggregate of multiple TE links that operates over could have been advertised in
   their own right. All TE links that are collected into a GMPLS
       WDM network, or an MPLS-TE network operating over TE 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-technology TE network where link 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, the virtual
   link), a link advertised bundle may be a TE link, constructed from FA-LSPs or a
       routing link. In the second instance, the LSP is used to form a virtual 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 shortcuts
   links.

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 common possible to signal an LSP and automatically coordinate
   its use them as described in case 4 and even advertisement in this case, only when the egress of the LSP is the final
       destination any of the traffic carried.

       g. It would ways described in Section 1.3
   with minimum involvement from an operator. The mechanisms used should
   be unusual although applicable to numbered and unnumbered links, and should not impossible
   require implementation complexities.

1.3. Existing Mechanisms

   This section briefly introduces existing protocol mechanisms used to use a
       hierarchical LSP as an IGP shortcut within
   satisfy the control plane.

    1.3. Problem Statement

       The extensions desired function described in this document Section 1.2.

1.3.1. LSP Setup

   Both unidirectional LSPs and bidirectional LSPs are intended for
       dynamically signaled bi-directional Forwarding Adjacency LSPs
       (FA-LSPs). In particular this document addresses from the following
       points:

         (1) How
   ingress label switching router (LSR) to let the 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 of LSR. That is, the
   ingress LSR is the initiator, and the egress nodes.

         (2) How to indicate that a new learns about the LSP should be treated as part of
            a TE link bundle
   through the signaling protocol [RFC3209], [RFC3473].

1.3.2. Routing Adjacency Establishment and advertised as part Link 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 identify each router know the routing instance in which such an
            advertisement should happen.

       We should note identity
   of the router at the other end of the link connecting the routers,
   and know that these aspects are equally applicable the IGP is to both
       numbered and unnumbered TE links.
       In order be 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 LSP network.

   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 able IGPs to advertise the
       LSP as a TE link it needs to know that such an advertisement is
       desirable, properties
   ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and it
   also needs to know the advertise link properties in GMPLS networks ([RFC4202],
   [RFC4203], and [RFC5307]).

   TE Router ID of the
       ingress LSR. (Please recall that the Router ID of link advertisement can be performed by the other end same instance of the link
   IGP as is set in the Link-ID sub-TLV of used for normal link state advertisement, or can use a
   separate instance. Furthermore, the Link TLV ends of the a TE Opaque-LSA [RFC3630].) If the LSP is link advertised in
   an IGP do not need to form part of a TE
       link bundle, routing adjacency. This is particularly
   the egress must also know case with FAs as described in Section 1.1.5.

1.3.4. Configuration and Management Techniques

   LSPs are usually created as the identity result of the
       bundle.

       When the mechanism set out in section 1.1 a management action. This
   is true even when a control plane is used for numbered
       FAs, there ? the management action is no way
   a request to carry the TE Router ID of the ingress
       LSR in the RSVP signaling message (Path message) and there is no
       way control plane to indicate that signal the LSP.

   If the new LSP 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 and H-LSP or S-LSP, management commands
   can be used to deduce that install the LSP forms
       that TE as a link. The egress link must learn the TE Router ID of the
       ingress node before it can advertise be 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 a new TE link.

       [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 the LSP is to be advertised used as part of a TE link, and it contains link bundle, the TE
       Router ID operator must
   decide which bundle it forms part of and ensure that that information
   is configured at the ingress LSR.  This mechanism resolves many of and 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 be LSP not being used for numbered FAs as currently defined, and so (a waste of resources) or the problem
       remains for numbered TE links.

       Related to LSP being made
   available in the above problem, a few key observations are worth
       noting:

       6. The term FA is applicable only when wrong way with some impact on traffic engineering.

1.3.5. Signaled Unnumbered FAs

   [RFC3477] describes how to establish an LSP is created and used to 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 of routing
   protocol as advertises the IGP, and is used as a (TE)
          link by another instance of IGP. This leaves open the question
          of advertising a TE link into a different instance of the IGP
          as is needed in multi-region/multi-layer networks [MLN-REQ],
          and how links 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 with link. That is,
   [RFC3477] describes how to create an IGP neighbor adjacency. We
          call it a routing adjacency (RA). unnumbered FA.

   The decision mechanism, 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 indicate defined in Section 3 of [RFC3477], is briefly as
   follows:

   - The ingress of the choice to LSP signals the Egress node is needed.

       7. [RFC4206] provides LSP as normal using a way to exchange numbered identifiers Path
     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 presence link 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 trigger identifies:
     - The egress's LSR Router ID
     - The egress's interface ID for the TE link advertisement at being created.

   - Following the exchange of the Path and Resv messages, both the
     ingress and the egress node.

       8. It is important to note know that an the LSP that is set up in a server
          GMPLS transport network and to 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 is the case
          regardless same instance of whether the GMPLS network is packet- or non-
          packet-capable.

       9. When an egress checks the address of routing protocol as was used to
     advertise the advertised TE link links that it traverses, and also know the
     unnumbered interface identifiers to
          find use 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 described a TE link that is identified using IPv4
   addresses in section
          1.1), it must check the Link-ID address same instance of all received TE
          advertisements against its own TE Router ID.  If it matches
          its own TE Router ID, the egress checks the advertising router
          ID of routing protocol as advertised
   the TE advertisement against the ingress addresses of
          all LSPs for which links it traverses (that is, as a numbered FA).

   The mechanism, as defined in [RFC4206], is the egress.  It is an assertion briefly as follows:

   - The ingress of the authors that this method is not scalable due LSP signals the LSP as normal using a Path
     message, and sets the IPv4 tunnel sender address to the amount
          of processing needed IP address
     it will use to identify its interface for all the TE Link State Advertisements
          (LSAs).

       10.Further, if link being
     created. This is one address from a set /31 pair.

   - The egress of LSPs are the LSP responds as normal to be bundled into a single TE
       link [RFC4201] then not only is accept the LSP and set
     it necessary up. It infers the address that it must assign to identify to its
     interface for the
       egress that TE link being created as the partner address of
     the /31 pair.

   - The ingress decides whether the LSP will is to be advertised as part of a TE link,
     link (i.e., as an FA). If so, it
       is also necessary to indicate advertises the identity of link in the TE link. This
       identity is distinct from IGP
     in the identity of usual way.

   - If the component link.
       Thus, in this case an additional identifier link 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 for done. If
     the TE link during FA-LSP establishment, and
       this can be used as a notification to is bidirectional, the egress that must also advertise the LSP
       will be used link,
     but it does not know that advertisement is required as a TE link. So, for unnumbered TE links, there is
       a well-defined no
     indication available, and this could be
       documented and used as a trigger for TE link in 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 numbers
     egress it must check to FAs, especially in see whether it is the case egress of large
       networks.  Some operators though prefer the LSP
     that formed the link. Typically this means:
     - Check to consistently use
       numbered TE links for both static and dynamic (that is, FA) TE
       links see if the link advertisement is new
     - Check to see if the Link-ID address in their networks. In the case of numbered received advertisement
       matches its own TE links,
       however, there Router ID
     - Checks the advertising router ID from the advertisement against
       the ingress address of each LSPs for which it is no available indication to allow the egress to
       know that an
     - Deduce the LSP should be that has been advertised as a TE link.

       In addition, using unnumbered TE links does not address the link and issue of advertising TE links into a different instance of
       the
       IGP. There corresponding advertisement for the reverse direction.

   It is no defined mechanism to identify whether it should possible 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 endpoints fair
   amount of an LSP.  But
       LMP peer discovery would be required for dynamic LMP peering processing required, and
       is this does not currently specified.  In addition, the concept scale well in large
   networks.

   No explanation is provided in [RFC4206] of a
       remote LMP adjacency remains unproven.  Lastly, there would be a
       requirement how to create numbered
   IPv6 FAs.

   Note that all layers/regions this 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 be section provides a brief outline of the case required protocol
   extensions.

1.4.1. Efficient Signaling of Numbered FAs

   The mechanism described in existing networks and would put
       undue burden on Section 1.3.6. is inefficient. The egress
   must wait until it receives an advertisement from the network operator ingress before
   it knows that the LSP is to deploy another protocol.

    1.5. Contents of This Document

       This document provides be installed as a consolidated way of exchanging TE link
       identifiers when and advertised
   as an LSP FA. Further, it must parse all received advertisements to
   determine if any is established through signaling. It
       also provides a mechanism the trigger for it to allow advertise an FA.

   An efficient signaling mechanism is required so that the egress is
   informed by the ingress to control
       whether, and into during 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 proposed FA.

   A signaling mechanism applies
       equally is needed to Hierarchical LSPs (H-LSPs) and Stitchable LSPs (S-
       LSPs).

       The method described below extends identify the method described in
       [RFC3477], use to which is applied for an FA-LSP represented as LSP
   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 Solution LSP For use in Another Network

   The following method allows existing signaling/routing mechanisms are designed for use in the ingress and egress LSRs to
       exchange
   creation of FAs. That is, the TE link addresses or link identifiers (including the
       node ID) of created is advertised in the ends of a
   single IGP instance.

   The numbered or unnumbered TE link to mechanism (Section 1.3.6) could, in theory, be
       formed from
   used in an LSP.  It MLN with multiple IGP instances if the addressing model is an extension of
   kept consistent across the procedures
       defined networks, 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, intends interfaces.

   A signaling mechanism is required to advertise
       this LSP as a TE link indicate in IS-IS or OSPF [RFC4206], the ingress
       LSR MUST allocate an address or identifier to which IGP instance
   the TE link (just
       like for any other TE link), and it MUST do this before the should be advertised.

1.4.4. Signaling an LSP
       setup request is signaled.  Moreover, the Path message used for
       establishing the LSP Use in a Link Bundle

   A signaling mechanism is required to indicate that will be used an LSP is intended
   to form the TE a component link MUST
       contain the LSP_TUNNEL_INTERFACE_ID object (as extended of 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, then to identify the egress LSR (assuming it
       accepts
   bundle and the LSP request) MUST allocate an address or identifier
       to IGP instance in which the TE link that will be formed (just like bundle is advertised.

1.4.5. Support for any other IPv4 and IPv6

   The protocol mechanisms must support IPv4 and IPv6 numbered or and
   unnumbered TE link).  Furthermore, the Resv message links.

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 is unnumbered FAs as defined in
   [RFC4206] and [RFC3477] must continue to be advertised as a TE link, the
       Tunnel Sender Address supported, 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 Object CCAMP working group established
   that there are no significant deployments of numbered FAs established
   using the Path
       message MUST be technique described in [RFC4206] and set to the TE Router ID out 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 that mechanisms 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 from extended 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].

       Once object identify the egress LSR has successfully sent a Resv message as
       described above
   address type for which it SHOULD advertise the applies.

2.2. LSP as Usage 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 and new Actions
   field to say how the LSP has been successfully
       established, the ingress LSR SHOULD advertise the is to be used. The following categories are
   supported:
   - LSP is used as a TE
       link using the addresses/identifiers exchanged.

       Once the an 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 an used to form a routing adjacency
   - LSP is to be used as a to form an advertised TE link and allows the ingress
       and egress LSRs to exchange addresses or identifiers for that TE
       link, during a routing adjacency
   - LSP setup.

       However, it forms a private link and is also necessary not advertised

2.3. IGP Instance Identification

   An optional TLV is added to indicate the LSP_TUNNEL_INTERFACE_ID object to
   identify the IGP instance into which instance of the IGP link formed by the advertisement should LSP is to
   be made.  This advertised. If the TLV is only
       necessary if absent and the LSP link is to be advertised
   as a TE link into a
       different instance of the IGP, and indicated by the default behavior may
       safely be left with Actions field, the LSP link is advertised into in the same
   instance of the IGP.

       Indication of the IGP in which as was used to advertise the advertisement TE 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 within used as a network, and that ingress and egress
       LSRs have the same understanding component link of these numbers.  This is a
       management configuration exercise outside the scope of this
       document.

       Once these numbers have been assigned, they MAY be signaled as
       additional information in link bundle, the
   LSP_TUNNEL_INTERFACE_ID object refers to
       indicate to which instance of the IGP bundle indicating how
   the object applies.

       The IGP instance identifier value of 0xffffffff bundle is reserved to
       indicate that addressed and used, and a new TLV indicates the TE
   component link SHOULD be advertised into the same
       instance of the IGP as was used to establish the LSP.  Similarly,
       absence of the IGP instance identifier means for the link that an FA is to be
       established (in the same IGP instance).

    3.2. LSP advertisement creates.

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
       needs work, so that ingress nodes do not have
     to create a full routing adjacency or forwarding adjacency
       or just need be 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 treat achieve
   the LSP as a local virtual link. function described in the previous section.

3.1. LSP_TUNNEL_INTERFACE_ID Object

   The
       extensions principal 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 specify next section. Subsequent sections
   describe new variants of the LSP
       advertisement object (denoted by new Class Types), and usage treatment.

       It is not mutually exclusive whether
   additional information carried in the LSP has routing
       adjacency object by means of extensions.

3.1.1. Existing Definition and whether it has forwarding adjacency. The LSP can
       have both routing Usage

   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 LSP LSP_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 the establish an LSP has only forwarding adjacency, it is
       used that will be
   advertised as an unnumbered TE link in the same instance of the IGP
   as TE-link was used to carry only MPLS labeled packets. If advertise the LSP
       has only routing adjacency, it is used as IP link to carry only
       pure IP datagram packets.
       Note TE links that the LSP which has only forwarding adjacency traverses. 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 created unchanged and operates as summarized
   in the optical
       domain (TDM, LSC, or FSC). We do Section 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 reduce make any suggestions about where in Path or Resv
   messages the amount LSP_TUNNEL_INTERFACE_ID object should be placed. See
   Section 3.5 for recommended placement of overhead this 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 whether the 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 there LSP_TUNNEL_INTERFACE_ID object is currently no way defined
   to
       signal that carry an LSP will be used as part of a bundle unnumbered interface identifier and to
       identify the bundled link to indicate 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 identify IGP the consequent TE link bundle to
       which the LSP will belong.  Thus multiple LSPs may should be signaled
       with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID
       object.  When
   advertised. This does not deprecate the LSP is to form a component link, use of C-Type 1.

   The format of the
       LSP_TUNNEL_INTERFACE_ID object 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
       TLV be 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 identify the component settings 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 may
          1 means that the LSP is not to be used as a numbered or
       unnumbered identifier.

       Multiple LSPs TE link. It may
            still be signaled with used as an IP link providing a routing adjacency as
            defined by the same address/identifier
       in R-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_ID link 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 defined is carried in [RFC3477] has a
       class number of 193, which designates Path 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 ignore Resv
   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
       types is 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 of the 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 one Identification 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 instances that 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 Target IGP Instance set as
   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 by defined
   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 present

   The TLV has meaning only in a Path message it indicates that the
       LSP being established message. It SHOULD NOT be advertised by included
   in the egress LSR as LSP_TUNNEL_INTERFACE_ID object in a TE link, Resv message and that unnumbered link identifier is MUST be
   ignored if found.

   If the ingress'
       identifier for P-flag in the TE link.

       Note that since this form Actions field of the LSP_TUNNEL_INTERFACE_ID
   object does not contain a
       target IGP instance identifier it cannot identify in a specific
       instance of Path 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 needs instance to
       be specified. Thus, when C-Type 1 is used, use for the TE link SHOULD be
       advertised only into advertisement. If the TLV is absent,
   the same instance of the IGP should be used as was is used to
       create advertise
   the LSP.  That is, TE links that the use of C-Type 1 is unchanged from
       [RFC3477] and is used to create LSP traverses. Thus, for an unnumbered Forwarding
       Adjacency.

       This object FA, the TLV can appear in either a Path message be
   omitted; alternatively, the IGP Instance TLV may be present
   identifying the IGP instance or a Resv
       message.  In carrying the former case, we call it reserved value
   0xffffffff.

   If the "Forward Interface
       ID" for that LSP; P-flag in the latter case, we call it the "Reverse
       Interface ID" for Actions field in the LSP.

       A Path or LSP_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 of is set (i.e., one) indicating that the LSP_TUNNEL_INTERFACE_ID Object LSP
   is
       defined not to carry an IPv4 numbered interface address be advertised as a link, this TLV SHOULD NOT be present and to
       indicate into which instance of the IGP the consequent TE link
       should
   MUST be advertised. ignored if encountered.

   The format of the object TLV 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)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Target                   IGP Instance (32 bits)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |ACTION |                PADDING                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           TLVs Identifier                     |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       ACTION: This field specifies how

     IGP Instance Identifier

       A 32-bit identifier be assigned to each of the LSP advertisement IGP instances
       within a network, such that ingress and usage
       treatment. It indicates if the egress LSR needs to create LSRs have the same
       understanding of these numbers. This is a full
       routing adjacency or forwarding adjacency management
       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 treat mean that the LSP is to be
       advertised in the same instance of the IGP as a local virtual link. It takes was 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 FA
   to be used and is only advertised into advertised.

   If the MPLS-TE
       topology. We should note that it assures B-flag in the backward
       compatibility with Actions field of the method to exchange unnumbered FA
       information described in [RFC3477].

       "0001": LSP is an RA and LSP_TUNNEL_INTERFACE_ID
   object is only advertised into set, the IP network.
       "0010": LSP is an RA and FA other fields of the object apply to the link
   bundle itself. That is, the interface identifiers (numbered or
   unnumbered) and is advertised the other flags in both IP the Actions field apply to the
   link bundle and
       MPLS-TE topologies.
       "0011": not to the component link that the LSP is neither will form.

   Furthermore, the FA nor RA IGP Instance Identifier TLV (if present) also
   applies to the link bundle and is not to be used as a local
       virtual the component link.

   In this case order to exchange the LSP is advertised neither in IP
       nor MPLS topology.
       The Padding MUST be identity 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 appear out in either a Path message or a Resv
       message.  In the former case, we call it
   next sections. If the "Forward Interface
       Address" for that LSP; B-flag is set in the latter case, we call it Actions field of the
       "Reverse Interface Address" for
   LSP_TUNNEL_INTERFACE_ID object in the LSP.

    3.4.3. IPv6 numbered link

       A new C-Type variant Path message, exactly one of
   these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID Object is
       defined to carry an IPv6 numbered interface address object in
   both the Path and Resv objects.

3.3.1. Unnumbered Component Link Identification

   If the component link is to
       indicate into which instance of be unnumbered, the IGP Unnumbered 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 of Value 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                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           TLVs                   Component 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 instance identifier

       A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object that is
       defined to carry an unnumbered interface identifier and assigned to
       indicate into which instance of this component link
       within the IGP bundle [RFC4201].

3.3.2. IPv4 Numbered Component Link Identification

   If the consequent TE component link
       should be advertised.  This does not deprecate is 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 object TLV 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" for                         IPv4 Address                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     IPv4 Address

       The IPv4 address that LSP; in the latter case, we call it the
       "Reverse Interface ID" for is assigned to this component link within
       the LSP.

    3.4.5. Message Formats

       [RFC3477] does not state where in bundle.

3.3.2. IPv6 Numbered Component Link Identification

   If the Path message or Resv
       message component 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, this IPv6
   Numbered Component Link Identifier TLV is not a problem.
       However, it used. The TLV is RECOMMENDED that the LSP_TUNNEL_INTERFACE_ID
       object(s) be placed formatted
   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 of
   the LSP_TUNNEL_INTERFACE_ID object have Value 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 contains IPv6 address that is assigned to this component link within
       the total length bundle.

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 Type LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and Length fields in bytes A value field whose length
   if such an object is not a multiple present, all other instances of four the
   LSP_TUNNEL_INTERFACE_ID object MUST be zero-padded so include an IGP Instance
   Identifier TLV with IGP Instance Identifier set to a value that
   identifies some other IGP instance (in particular, not the TLV value
   0xffffffff).

   If the link created from an LSP is
       four-byte aligned.

       This document defines two Type values to be advertised in the same IGP
   instance as was used to specify advertise the
       component link identifier TE links that the sending LSR has assigned to
       the LSP if
   traverses, the addresses for the new link and that for the links it forms part of a TE
   is built from MUST come from the same address space.

   If the link bundle.  The consequent
       TLV formats are shown is 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 TLV IGP the TE Router ID of the ingress LSR is present if taken from the
   Tunnel Sender Address in the Sender Template object signaled in the
   Path message. It is assumed that the ingress LSR knows the signaled TE Router
   ID of the egress LSR since it has chosen to establish an LSP is to be used that
   LSR and plans to use the LSP as an
       unnumbered component link of a bundled TE link.  In this case,
       the identifier (numbered

   The link interface addresses or unnumbered) in link interface identifiers for the main body of
   forward and reverse direction links are taken from the
       LSP_TUNNEL_INTERFACE_ID
   LSP_TUNNEL_INTREFACE_ID object indicates on the TE link bundle of
       which this Path 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 Identifier advertisement of this TLV specifies any link
   that the unnumbered identifier LSP 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 assigned RECOMMENDED 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 within handle 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 NOT error arises after the LSP has been successfully
   set up, the PathErr SHOULD be present in sent with the same instance of Path_State_Removed flag
   [RFC3473] clear so that the
       LSP_TUNNEL_INTERFACE_ID object LSP 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 0 follows 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 signaled    Hierarchical LSP is to be used as a
       numbered not 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 of identifier 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 of object. Since these reasons all represent
   errors rather than negotiable parameter-mismatches, the
       LSP_TUNNEL_INTERFACE_ID object indicates ingress
   SHOULD respond with a PathTear to remove the TE link bundle LSP. The ingress MAY use
   a ResvErr with one of
       which this the following error codes, allowing the egress
   the option to correct the error in a new Resv message, or to tear the
   LSP is with a component, and the IPv4 Address field of
       this TLV specifies the numbered identifier PathErr with Path_State_Removed flag set. An ingress that is assigned to
       this component link within
   uses the bundle.

       This TLV ResvErr MUST NOT be present in take precautions against a protocol loop where
   the same instance of egress responds with the same LSP_TUNNEL_INTERFACE_ID object as a TLV with
   the same or different) issues.

   Error | Error | Error-case
   code  | value |
   ------+-------+------------------------------------------------------
    34       11    Link address type 1 (unnumbered or 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 advertise identifier 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
       advertised LSP_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 support a node that
   does not understand the TE links, or
       another IGP instance.  In object SHOULD ignore the former case, object but forward
   it, unexamined and unmodified. Thus there are no issues with transit
   LSRs supporting the address space for pre-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 be new Class Types defined in this document.

   - It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID
     objects with the same new Class Types defined in this document as that used to establish the
       LSPs.
     described in [RFC2205]. In the latter any 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 used such 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 from egress.

   - It will continue to use the
       Tunnel Sender Address LSP_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
       assumed
     therefore safe to assume that the back-level ingress LSR knows the TE Router ID of the LSRs will not use
     this mechanism.

   A back-level egress LSR since it has chosen to establish an LSP to that LSR
       and plans node will behave as follows:

   - It will continue to use support the LSP LSP_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 for Path message that carries an
     LSP_TUNNEL_INTERFACE_ID object with any of the forward and reverse direction links are taken from new Class Types
     defined in this document using the
       LSP_TUNNEL_INTREFACE_ID object on procedures of [RFC2205]. This
     will inform the Path and Resv messages
       respectively.

       Address overlap checking for these objects MUST be turned off
       when ingress that the LSA egress is advertised into a IGP instance different from
       the one used back-level LSR.

   - It will not expect to establish the LSP because use the addresses MAY be
       allocated in both domains.

    4. Applicability Statement

       The method is applicable procedures for both hierarchical LSPs numbered FA
     establishment defined in [RFC4206] and LSP stitching [STITCH].

    5. Backward Compatibility Considerations

       The method does set 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 was

   The mechanisms in this document obsolete the
       attempt to implement numbered FAs that gave rise method 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-Types

5.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-Types object 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 assign create 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 to as 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-Types error 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. Acknowledgement below (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 and Drake, Yakov Rekhter Rekhter, 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

    9.1.

7.1. 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 MPLS Multiprotocol 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 Multiprotocol Y. 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-region GMPLS-Based Multi-
             Region and multi-layer networks Multi-Layer Networks (MRN/MLN)",
                 draft-ietf-ccamp-gmpls-mln-reqs, (work RFC 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's

8. Editors' Addresses

   Kohei Shiomoto
   NTT Network Service Systems Laboratories
   3-9-11 Midori
   Musashino, Tokyo 180-8585
   Japan
   Phone: +81 422 59 4402
   Email: shiomoto.kohei@lab.ntt.co.jp

   Adrian Farrel
   Old Dog Consulting
   EMail: adrian@olddog.co.uk

9. Authors' Addresses

   Richard Rabbat
   Google Inc.
   1600 Amphitheatre Pkwy
   Mountain View, CA 94043
   Email: rabbat@alum.mit.edu

   Arthi Ayyangar
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   United States of America
       Phone:
   Email: arthi@juniper.net

       Adrian Farrel
       Old Dog Consulting
       EMail: adrian@olddog.co.uk

   Zafar Ali
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Canada.
   EMail: zali@cisco.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 ietf-ipr@ietf.org
   ietf-ipr@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.