[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-shiomoto-ccamp-lsp-hierarchy-bis) 00 01 02 03 04 05 06 07 08 RFC 6107

    Network Working Group                             K. Shiomoto (NTT)
    Internet Draft                                   R. Rabbat (Google)
    Updates: 3477, 4206                  A. Ayyangar (Juniper Networks)
    Proposed Category: Proposed Standard  A. Farrel (Old Dog Consulting)
                                           Z. Ali (Cisco Systems, Inc.)
    Expires: August 2008                              February 22, 2008
    
    
    
                       Procedures for Dynamically Signaled
                        Hierarchical Label Switched Paths
                     draft-ietf-ccamp-lsp-hierarchy-bis-03.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 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 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 Multiprotocol Label Switching (GMPLS) Label
       Switched Paths (LSPs).  It describes extensions to allow an
       egress to identify that a bi-directional LSP will be used as a
    
    
    
    
    Shiomoto                Expires October 2007                [Page 1]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a
       Routing Adjacency (RA). In addition, the document also discusses
       the issue of how to indicate that an LSP should be advertised as
       a traffic engineering (TE) link into a different instance of the
       IGP, and how to identify the instance that should be used.
    
    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
    1.1. LSP Hierarchy............................................3
    1.2. LSP advertisement and Usage...............................4
    1.3. Problem Statement........................................6
    1.4. Current Approaches and Shortcomings.......................8
    1.5. Contents of This Document.................................9
    2. Revision history...........................................9
    2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9
    2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9
    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 and Usage Identification................11
    3.3. Bundling.................................................12
    3.4. LSP_TUNNEL_INTERFACE_ID Object............................12
    3.4.1. Unnumbered link.........................................13
    3.4.2. IPv4 numbered link......................................14
    3.4.3. IPv6 numbered link......................................15
    3.4.4. Unnumbered link with target IGP instance identifier......16
    3.4.5. Message Formats........................................16
    3.5. TLVs.....................................................17
    3.5.1. Unnumbered Component Link Identifier....................17
    3.5.2. IPv4 Numbered Component Link Identifier.................18
    3.6. LSA advertisement........................................18
    4. Applicability Statement.....................................19
    5. Backward Compatibility Considerations.......................19
    6. Security Considerations.....................................19
    7. IANA Considerations........................................20
    8. Acknowledgement............................................20
    9. References.................................................20
    9.1. Normative References.....................................20
    
    
    
    Shiomoto                 Expires August 2008               [Page 2]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
    9.2. Informative References....................................20
    Author's Addresses............................................21
    Intellectual Property Statement................................22
    Copyright Statement...........................................23
    
    1. Introduction and Problem Statement
    
    1.1. LSP Hierarchy
    
       LSP hierarchy has been developed to improve the scalability of
       Generalized Multi-Protocol Label Switching (GMPLS) by allowing
       Label Switched Paths (LSPs) to be aggregated into a hierarchy of
       such LSPs [RFC4206]. An LSP may be advertised as a traffic
       engineering (TE) link for use within the same instance of the
       control plane as was used to set up the LSP. This TE link is
       called a Forwarding Adjacency (FA), and the LSP is known as an
       FA-LSP.
    
       [RFC4206] defines the operation as follows for a numbered FA:
    
       1. The ingress signals the LSP using a /31 sender address that it
          allocates as the source address in the signaling message
          (tunnel sender address in the Sender Template object of the
          Path message), and targeting the TE router ID of the egress
          (destination address in the Sender object of the Path
          message).
    
       2. The egress sets up the LSP using normal procedures and
          allocating the partner address of the assigned /31 address in
          the local interface address.
    
       3. The ingress then forms a Forwarding Adjacency (FA) out of that
          LSP by advertising it as a Traffic Engineering (TE) link using
          the routing protocol (OSPF/ISIS) and  using the /31 address to
          identify the local end of the TE link.
    
       4. When the egress receives the TE link advertisement, it checks
          the Link-ID address 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 of the TE advertisement
          against the ingress addresses of all LSPs for which it is the
          egress and finds the address match with the advertising router
          ID of the TE advertisement.
    
    
    
    
    
    
    Shiomoto                 Expires August 2008               [Page 3]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       5. The egress then advertises the FA LSP as a TE link setting the
          advertising TE Router ID in the Link-ID and the partner
          address of the assigned /31 address in the local interface
          address.
    
       Nesting of LSPs originated by other LSRs into that LSP can be
       achieved by using the label stack construct.
    
    
    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 LSP can be used to carry
       traffic and potentially advertised as a link by a routing
       protocol.
    
       First, the LSP can be used either as a link inside or outside
       the network that was used to form the LSP. In the former case,
       the LSP can carry traffic that could have been routed down the
       TE links that are navigated by the LSP. In the latter case, it
       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
       in packet networks as they are the only type of network that
       supports nesting of LSPs within the same 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 LSP can be advertised by the
       routing protocol as available to carry traffic, or can be kept
       as a private link known only to the head and tail end LSRs.
    
       These two options give rise to four possible combinations as
       follows.
    
       1. The LSP is created and advertised as a TE link in the same
       instance 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 routing adjacency is formed
       over the LSP.
    
       2. The LSP is created and made available to carry traffic in the
       same network as the links that it traverses, but it is not
       advertised. The availability of the LSP is private to the end
    
    
    
    Shiomoto                 Expires August 2008               [Page 4]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       points. This is a hierarchical LSP, but not an FA. It might be
       used for inter-domain traffic engineering [RFC4726].
    
       3. The LSP is created as before, but is advertised as a link in
       another instance of the routing protocol. This method of
       operation is particular to client/server networks and especially
       multi-layer networks [MLN-REQ], [PCE-INTER-LAYER-REQ].
    
       4. An LSP can be created and used by a client network without
       being advertised in the client 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 the
       client network.
    
       Notes:
    
       a. Case 1 includes the multi-layer traffic engineering scenario
       where a single instance of the routing protocol is used across
       both layers. This situation was particularly envisaged in
       [RFC4206].
    
       b. The example cited in case 2 is special because the
       hierarchical LSP is edge-to-edge within a particular domain and
       no TE links are advertised outside of the domain (by definition
       of the domain). The purpose of the TE link is to carry traffic
       across the domain and not to carry intra-domain traffic.
       Advertising the TE link within the domain might cause internal
       traffic to take longer paths as it seeks to use the hierarchical
       LSP.
    
       c. Case 3 is not the only option for the multi-layer network as
       explained in Note a.
    
       d. The client network in case 3 may be a different technology TE
       network (such as a GMPLS TDM network that operates over a GMPLS
       WDM network, or an MPLS-TE network operating over a GMPLS
       optical network), a same-technology TE network where LSP nesting
       is allowed (for example, an MPLS-TE network operating over
       another MPLS-TE network), or a non-TE network (such as an IP
       network operating over an MPLS-TE or GMPLS network of any
       technology). Thus, the link advertised may be a TE link, 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
    
    
    
    Shiomoto                 Expires August 2008               [Page 5]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       within different IGP areas [RFC4105].
    
       f. IGP shortcuts should be treated with extreme caution when
       they are created and used in the same IP/MPLS network. Thus, it
       may be more common to use them as described in case 4 and even
       in this case, only when the egress of the LSP is the final
       destination of the traffic carried.
    
       g. It would be unusual although not impossible to use a
       hierarchical LSP as an IGP shortcut within the control plane.
    
    1.3. Problem Statement
    
       The extensions described in this document are intended for
       dynamically signaled bi-directional Forwarding Adjacency LSPs
       (FA-LSPs). In particular this document addresses the following
       points:
    
         (1) How 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
            the ingress and egress nodes.
    
         (2) How to indicate that a new LSP should be treated as part of
            a TE link bundle and advertised as part of that bundle.
    
         (3) How to identify the routing instance in which such an
            advertisement should happen.
    
       We should note that these aspects are equally applicable to both
       numbered and unnumbered TE links.
       In order for the egress of an LSP to be able to advertise the
       LSP as a TE link it needs to know that such an advertisement is
       desirable, and it also needs to know the TE Router ID of the
       ingress LSR. (Please recall that the Router ID of the other end
       of the link is set in the Link-ID sub-TLV of the Link TLV of the
       TE Opaque-LSA [RFC3630].) If the LSP is to form part of a TE
       link bundle, the egress must also know the identity of the
       bundle.
    
       When the mechanism set out in section 1.1 is used for numbered
       FAs, there is no way to carry the TE Router ID of the ingress
       LSR in the RSVP signaling message (Path message) and there is no
       way to indicate that 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
    
    
    
    Shiomoto                 Expires August 2008               [Page 6]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       learn about the new TE link and to deduce that the LSP forms
       that TE link. The egress must learn the TE Router ID of the
       ingress node before it can advertise the FA as described in
       Section 1.2. Note further, that in this approach, 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 as a TE link, and it contains the TE
       Router ID of the ingress LSR.  This mechanism resolves many of
       the issues listed above, and provides a solution for unnumbered
       TE links, however, the LSP_TUNNEL_INTERFACE_ID object cannot be
       used for numbered FAs as currently defined, and so the problem
       remains for numbered TE links.
    
       Related to the above problem, a few key observations are worth
       noting:
    
       6. The term FA is applicable only when an LSP is created and used
          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 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 to identify which instance of the IGP should be used.
          In addition, the TE link advertised into the different IGP
          instance may be associated with an IGP neighbor adjacency. We
          call it a routing adjacency (RA). The decision 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 the choice to the Egress node is needed.
    
       7. [RFC4206] provides a way to exchange numbered identifiers for
          the TE link, but this does not clearly state that the Ingress
          node can use presence of the LSP_TUNNEL_INTERFACE_ID object as
          a trigger for TE link advertisement at the egress node.
    
    
    
    
    
    
    
    
    Shiomoto                 Expires August 2008               [Page 7]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       8. It is important to note that an LSP that is set up in a server
          GMPLS transport network and 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 of whether the GMPLS network is packet- or non-
          packet-capable.
    
       9. When an egress checks the address of the advertised TE link to
          find the LSP sender (Recall step (4) as described in section
          1.1), it must check the Link-ID address 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 the TE advertisement against the ingress addresses of
          all LSPs for which it is the egress.  It is an assertion of
          the authors that this method is not scalable due to the amount
          of processing needed for all the TE Link State Advertisements
          (LSAs).
    
       10.Further, if a set of LSPs are to be bundled into a single TE
       link [RFC4201] then not only is it necessary to identify to the
       egress that the LSP will be advertised as part of a TE link, it
       is also necessary to indicate the identity of the TE link. This
       identity is distinct from the identity of the component link.
       Thus, in this case an additional identifier needs to be signaled,
       but none is currently available.
    
    1.4. Current Approaches and Shortcomings
    
       [RFC3477] provides a mechanism to exchange unnumbered
       identifiers for the TE link during FA-LSP establishment, and
       this can be used as a notification to the egress that the LSP
       will be used as a TE link. So, for unnumbered TE links, there is
       a well-defined indication available, and this could be
       documented and used as a trigger for TE link advertisement by
       the egress.
    
       The use of unnumbered TE links may be arguably more sensible
       than assigning numbers to FAs, especially in the case of large
       networks.  Some operators though prefer to consistently use
       numbered TE links for both static and dynamic (that is, FA) TE
       links in their networks. In the case of numbered TE links,
       however, there is no available indication to allow the egress to
       know that an LSP should be advertised as a TE link.
    
       In addition, using unnumbered TE links does not address the
       issue of advertising TE links into a different instance of the
    
    
    
    Shiomoto                 Expires August 2008               [Page 8]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       IGP. There is no defined mechanism to identify whether it should
       be advertised as an FA, 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 of an LSP.  But
       LMP peer discovery would be required for dynamic LMP peering and
       is not currently specified.  In addition, the concept of a
       remote LMP adjacency remains unproven.  Lastly, there would be a
       requirement that all layers/regions in a MLN network run LMP.
       This may not be the case in existing networks and would put
       undue burden on the network operator to deploy another protocol.
    
    1.5. Contents of This Document
    
       This document provides a consolidated way of exchanging TE link
       identifiers when an LSP is established through signaling. It
       also provides a mechanism to allow the ingress to control
       whether, and into which IGP instances, an LSP is advertised as
       an FA and/ or RA by the egress. The proposed mechanism applies
       equally to Hierarchical LSPs (H-LSPs) and Stitchable LSPs (S-
       LSPs).
    
       The method described below extends the method described in
       [RFC3477], which is applied for an FA-LSP represented as 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
    
    
    
    
    
    Shiomoto                 Expires August 2008               [Page 9]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
    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
    
       The following method allows the ingress and egress LSRs to
       exchange the link addresses or link identifiers (including the
       node ID) of the ends of a numbered or unnumbered TE link to be
       formed from an LSP.  It is an extension of the procedures
       defined in [RFC3477] for unnumbered TE links.
    
       If an ingress LSR that originates an LSP, intends to advertise
       this LSP as a TE link in IS-IS or OSPF [RFC4206], the ingress
       LSR MUST allocate an address or identifier to the TE link (just
       like for any other TE link), and it MUST do this before the LSP
       setup request is signaled.  Moreover, the Path message used for
       establishing the LSP that will be used to form the TE link MUST
       contain the LSP_TUNNEL_INTERFACE_ID object (as extended 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 the egress LSR (assuming it
       accepts the LSP request) MUST allocate an address or identifier
       to the TE link that will be formed (just like for any other
       numbered or unnumbered TE link).  Furthermore, the Resv message
       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 to be advertised as a TE link, the
       Tunnel Sender Address in the Sender Template Object of the Path
       message MUST be set to the TE Router ID of the ingress LSR. We
       should note that this is a change from the method described in
       [RFC4206].
    
       Once the egress LSR has successfully sent a Resv message as
       described above it SHOULD advertise the LSP as a TE link using
       the addresses/identifiers exchanged. Once the Resv has been
       processed by the ingress LSR and the LSP has been successfully
       established, the ingress LSR SHOULD advertise the LSP as a TE
       link using the addresses/identifiers exchanged.
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 10]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       Once the TE link advertisement has been flooded it 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 LSP is to be used as a TE link and allows the ingress
       and egress LSRs to exchange addresses or identifiers for that TE
       link, during LSP setup.
    
       However, it is also necessary to indicate into which instance of
       the IGP the advertisement should be made.  This is only
       necessary if the LSP is to be advertised as a TE link into a
       different instance of the IGP, and the default behavior may
       safely be left with the LSP advertised into the same instance of
       the IGP.
    
       Indication of the IGP in which the advertisement is to be made
       first requires that a 32-bit identifier be assigned to each of
       the IGP instances within a network, and that ingress and egress
       LSRs have the same understanding 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 the LSP_TUNNEL_INTERFACE_ID object to
       indicate to which instance of the IGP the object applies.
    
       The IGP instance identifier value of 0xffffffff is reserved to
       indicate that the TE 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 that an FA is to be
       established (in the same IGP instance).
    
    3.2. LSP advertisement and Usage Identification
    
       As mentioned earlier, the egress node also needs to know if it
       needs to create a full routing adjacency or forwarding adjacency
       or just need to treat the LSP as a local virtual link. The
       extensions defined in the following also specify the LSP
       advertisement and usage treatment.
    
    
    
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 11]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       It is not mutually exclusive whether the LSP has routing
       adjacency and whether it has forwarding adjacency. The LSP can
       have both routing and forwarding adjacency. In this case, the LSP
       can be used to carry both pure IP datagram packets and MPLS
       labeled packets. If the LSP has only forwarding adjacency, it is
       used as TE-link to carry only MPLS labeled packets. If the LSP
       has only routing adjacency, it is used as IP link to carry only
       pure IP datagram packets.
       Note that the LSP which has only forwarding adjacency is useful
       to improve the scalability. Suppose that distant PSC domains are
       connected by a set of lower-layer LSPs created in the optical
       domain (TDM, LSC, or FSC). We do 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 the amount of overhead 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 is currently no way to
       signal that an LSP will be used as part of a bundle and to
       identify the bundled link to which 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 the TE link bundle to
       which the LSP will belong.  Thus multiple LSPs may be signaled
       with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID
       object.  When the LSP is to form a component link, the
       LSP_TUNNEL_INTERFACE_ID object MUST also contain an additional
       TLV to identify the component link.  This may be a numbered or
       unnumbered identifier.
    
       Multiple LSPs may be signaled with the same address/identifier
       in the LSP_TUNNEL_INTERFACE_ID object.
    
    
    3.4. LSP_TUNNEL_INTERFACE_ID Object
    
       The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a
       class number of 193, which designates that a node that does not
    
    
    
    Shiomoto                 Expires August 2008              [Page 12]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       understand the object SHOULD ignore 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 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 for the Target
       IGP Instance field.  A Path or Resv message MUST NOT contain
       more than one instance of the LSP_TUNNEL_INTERFACE_ID object
       with C-Type 1, and if such an object is present, other instances
       of the object with any other C-Type value MUST NOT have Target
       IGP Instance set to 0xffffffff.
    
    3.4.1. Unnumbered link
    
       The unnumbered link identifier defined by [RFC3477] is not
       changed by this document.  Its usage also remains the same.
       That is, when present in a Path message it indicates that the
       LSP being established SHOULD be advertised by the egress LSR as
       a TE link, and that unnumbered link identifier is the ingress'
       identifier for the TE link.
    
       Note that since this form of the object does not contain a
       target IGP instance identifier it cannot identify a specific
       instance of the IGP into which this TE link should be advertised.
       Similarly, LSP advertisement and usage treatment also needs to
       be specified. Thus, when C-Type 1 is used, the TE link SHOULD be
       advertised only into the same instance of the IGP as was used to
       create the LSP.  That is, the use of C-Type 1 is unchanged from
       [RFC3477] and is used to create an unnumbered Forwarding
       Adjacency.
    
       This object can appear in either a Path message or a Resv
       message.  In the former case, we call it the "Forward Interface
    
    
    
    Shiomoto                 Expires August 2008              [Page 13]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       ID" for that LSP; in the latter case, we call it the "Reverse
       Interface ID" for the LSP.
    
       A Path or 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 the LSP_TUNNEL_INTERFACE_ID Object is
       defined to carry an IPv4 numbered interface address and to
       indicate into which instance of the IGP the consequent TE link
       should be advertised.
    
       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 (32 bits)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Target IGP Instance (32 bits)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |ACTION |                PADDING                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           TLVs                                |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
       ACTION: This field specifies how the LSP advertisement and usage
       treatment. It indicates if the egress LSR needs to create a full
       routing adjacency or forwarding adjacency or just need to treat
       the LSP as a local virtual link. It takes the following values:
    
       "0000": LSP is an FA and is only advertised into the MPLS-TE
       topology. We should note that it assures the backward
       compatibility with the method to exchange unnumbered FA
       information described in [RFC3477].
    
    
    
    
    
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 14]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       "0001": LSP is an RA and is only advertised into the IP network.
       "0010": LSP is an RA and FA and is advertised in both IP and
       MPLS-TE topologies.
       "0011": LSP is neither the FA nor RA and is to be used as a local
       virtual link. In this case the LSP is advertised neither in IP
       nor MPLS topology.
       The Padding MUST be set to zero on transmission, SHOULD be
       ignored and forwarded unchanged, and SHOULD be ignored on
       receipt.
       This object can 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.3. IPv6 numbered link
    
       A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is
       defined to carry an IPv6 numbered interface address and to
       indicate into which instance of the IGP the consequent TE link
       should be advertised.
    
       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 (128 bits)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               IPv6 Interface Address (128 bits)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               IPv6 Interface Address (128 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
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 15]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       Interface Address" for that LSP; in the latter case, we call it
       the "Reverse Interface Address" for the LSP.
    
    3.4.4. Unnumbered link with target IGP instance identifier
    
       A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is
       defined to carry an unnumbered interface identifier and to
       indicate into which instance of the IGP the consequent TE link
       should be advertised.  This does not deprecate the use of C-Type
       1, but extends its utility.
    
       The format of the 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)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               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 that LSP; in the latter case, we call it the
       "Reverse Interface ID" for the LSP.
    
    3.4.5. Message Formats
    
       [RFC3477] does not state where in the Path message or Resv
       message 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 is not a problem.
       However, it is RECOMMENDED that the LSP_TUNNEL_INTERFACE_ID
       object(s) be placed in the Path message immediately after the
       SENDER_TSPEC object, and in the Resv message immediately after
       the FILTER_SPEC object.
    
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 16]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
    3.5. TLVs
    
       All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the
       following format.
    
        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)        |       Length (16 bits)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Value (variable)                       |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    
       The length field contains the total length of the TLV including
       the Type and Length fields in bytes A value field whose length
       is not a multiple of four MUST be zero-padded so that the TLV is
       four-byte aligned.
    
       This document defines two Type values to be used to specify the
       component link identifier that the sending LSR has assigned to
       the LSP if it forms part of a TE link bundle.  The consequent
       TLV formats are shown 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 is present if the signaled LSP is to be used as an
       unnumbered component link of a bundled TE link.  In this case,
       the identifier (numbered or unnumbered) in the main body of the
       LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of
       which this LSP is a component, and the Component Link Identifier
       of this TLV specifies the unnumbered identifier that is assigned
       to this component link within the bundle.
    
    
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 17]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       This TLV MUST NOT be present in the same instance of the
       LSP_TUNNEL_INTERFACE_ID object 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 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type = 2            |          Length = 8           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address (32 bits)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    
       This TLV is present if the signaled LSP is to be used as a
       numbered component link of a bundled TE link.  In this case, the
       identifier (numbered or unnumbered) in the main body of the
       LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of
       which this LSP is a component, and the IPv4 Address field of
       this TLV specifies the numbered identifier that is assigned to
       this component link within the bundle.
    
       This TLV MUST NOT be present in the same instance of the
       LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered
       component link identifier).
    
    
    3.6. LSA advertisement
    
       The ingress and egress LSRs MAY advertise link state associated
       with TE links created as described above.  The link state may be
       advertised in either the same IGP instance as used to compute
       and signal the path for the LSPs that support the TE links, or
       another IGP instance.  In the former case, the address space for
       the link state MUST be the same as that used to establish the
       LSPs.  In the latter 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 by
       the advertised TE link without any ambiguity.
    
       In the IGP the TE Router ID of the ingress LSR is taken from the
       Tunnel Sender Address in the Sender Template object.  It is
       assumed that the ingress LSR knows the TE Router ID of the
       egress LSR since it has chosen to establish an LSP to that LSR
       and plans to use the LSP as a TE link.
    
    
    
    Shiomoto                 Expires August 2008              [Page 18]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       The link interface addresses or link interface identifiers for
       the forward and reverse direction links are taken from the
       LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages
       respectively.
    
       Address overlap checking for these objects MUST be turned off
       when the LSA is advertised into a IGP instance different from
       the one used to establish the LSP because the addresses MAY be
       allocated in both domains.
    
    4. Applicability Statement
    
       The method is applicable for both hierarchical LSPs [RFC4206]
       and LSP stitching [STITCH].
    
    5. Backward Compatibility Considerations
    
       The method does 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
       attempt to implement numbered FAs that gave rise to the work on
       this document.
    
    6. 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.
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 19]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
    7. IANA Considerations
    
       This document defines three new C-Types for the
       LSP_TUNNEL_INTERFACE_ID object.  The C-Types for this object are
       managed by IANA, and IANA is requested to assign values to the
       new C-Types as tabulated in section 2.2 and described in
       sections 2.2.2, 2.2.3 and 2.2.4.
    
    8. Acknowledgement
    
       The authors would like to thank John Drake and Yakov Rekhter for
       their valuable discussions and comments.
       Funding for the RFC Editor function is currently provided by the
       Internet Society.
    
    9. References
    
    9.1. Normative References
    
       [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.
    
       [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, K. and Rekhter, Y., "Signalling Unnumbered
                 Links in Resource ReSerVation Protocol - Traffic
                 Engineering (RSVP-TE)", RFC 3477, January 2003.
    
       [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]  Ayyangar, A. and J.P. Vasseur, "Label Switched Path
                 Stitching with Generalized MPLS Traffic Engineering",
                 draft-ietf-ccamp-lsp-stitching, (work in progress).
    
    9.2. Informative References
    
       [RFC3630]Katz, D., Kompella, K. and Yeung, D., "Traffic
                 Engineering (TE) Extensions to OSPF Version 2", RFC
                 3630, September 2003.
    
    
    
    Shiomoto                 Expires August 2008              [Page 20]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       [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)",
                 RFC 4204, October 2005.
    
       [RFC4726]Farrel, A., Vasseur, J.-P., and Ayyangar, A., " A
                 Framework for Inter-Domain Multiprotocol Label
                 Switching Traffic Engineering ",     RFC 4726, November
                 2006.
    
       [MLN-REQ]Shiomoto, K., et al, "Requirements for GMPLS-based
                 multi-region and multi-layer networks (MRN/MLN)",
                 draft-ietf-ccamp-gmpls-mln-reqs, (work in progress).
    
       [PCE-INTER-LAYER-REQ]  Oki, E. (Ed.), " PCC-PCE Communication
                 and PCE Discovery Requirements for Inter-Layer Traffic
                 Engineering ", draft-ietf-pce-inter-layer-req, (work in
                 progress).
    
    
    
    Author's 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
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 21]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       Richard Rabbat
       Google Inc.
       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
    
    
    
    Shiomoto                 Expires August 2008              [Page 22]


    Internet-Draft  draft-ietf-ccamp-lsp-hierarchy-bis-03  Feburuary 2008
    
    
       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
    
    
    
        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.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Shiomoto                 Expires August 2008              [Page 23]
    

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/