[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 (Nuova Systems)
     Proposed Category: Proposed Standard     A. Farrel (Old Dog Consulting)
                                                Z. Ali (Cisco Systems, Inc.)
     Expires: October 2007                                    April 26, 2007
     
     
     
        Procedures for Dynamically Signaled Hierarchical Label Switched Paths
                      draft-ietf-ccamp-lsp-hierarchy-bis-02.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 October 26, 2007.
     
     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 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
     
     
     
     
     Shiomoto                 Expires October 2007                  [Page 1]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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.........................................4
           1.4. Current Approaches and Shortcomings.......................6
           1.5. Contents of This Document.................................7
        2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.....7
        3. Proposed Solution..............................................7
           3.1. IGP Instance Identification...............................8
           3.2. LSP advertisement and Usage Identification................9
           3.3. Bundling..................................................9
           3.4. LSP_TUNNEL_INTERFACE_ID Object...........................10
              3.4.1. Unnumbered link.....................................10
              3.4.2. IPv4 numbered link..................................11
              3.4.3. IPv6 numbered link..................................12
              3.4.4. Unnumbered link with target IGP instance identifier.13
              3.4.5. Message Formats.....................................13
           3.5. TLVs.....................................................14
              3.5.1. Unnumbered Component Link Identifier................14
              3.5.2. IPv4 Numbered Component Link Identifier.............15
           3.6. LSA advertisement........................................15
        4. Applicability Statement.......................................16
        5. Backward Compatibility Considerations.........................16
        6. Security Considerations.......................................16
        7. IANA Considerations...........................................17
        8. Acknowledgement...............................................17
        9. References....................................................17
           9.1. Normative References.....................................17
           9.2. Informative References...................................17
        Author's Addresses...............................................18
        Intellectual Property Statement..................................18
        Copyright Statement..............................................19
     
     
     
     
     
     
     Shiomoto                 Expires October 2007                  [Page 2]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
     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.
     
        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.
     
     
     
     
     
     
     Shiomoto                 Expires October 2007                  [Page 3]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
     1.2. LSP advertisement and Usage
     
        There are three different ways in which traffic can be forwarded to
        an LSP. Similarly, the LSP can be advertised into the IP topology,
        the MPLS TE topology or both, depending on the intended usage.
     
        As GMPLS LSPs can be bidirectional, full routing adjacencies can be
        established over a bidirectional GMPLS LSP. When an LSP is used as an
        RA, it is advertised into IP network and can optionally be advertised
        into the MPLS topology. The notion of RA is only applicable to
        bidirectional LSPs.
     
        As mentioned above, there is no IGP adjacency over the LSP, when it
        is to be used as an FA. FA-LSPs can be advertised into the IP and/ or
        MPLS topologies. Notion of FA is equally applicable to the
        unidirectional as well as bidirectional LSPs.
     
        There are also scenarios where intent of establishing an LSP is to
        use it for traffic local to the Ingress/ Egress LSRs. In this case,
        the LSP is neither advertised into the IP nor in MPLS topologies. In
        this document, such LSPs are referred as local virtual links.
        Forwarding treatment for a local virtual link is based on a local
        decision.
     
     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 routing adjacency (RA),
            or is 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.
     
     
     
     Shiomoto                 Expires October 2007                  [Page 4]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        (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 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:
     
        1. 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], 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.
     
     
     
     
     
     Shiomoto                 Expires October 2007                  [Page 5]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        2. [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.
     
        3. 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.
     
        4. 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).
     
        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.
     
     
     
     
     Shiomoto                 Expires October 2007                  [Page 6]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        In addition, using unnumbered TE links does not address the issue of
        advertising TE links into a different instance of the IGP. There is
        no defined mechanism to identify whether it should be advertised as
        an FA, a full Routing Adjacency (RA), or a static 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. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00
     
        o Fixed page formatting
     
        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
     
     
     
     Shiomoto                 Expires October 2007                  [Page 7]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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.
     
        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 (that is, FA behavior).
     
        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.
     
     
     
     Shiomoto                 Expires October 2007                  [Page 8]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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.
     
        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.
     
        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
     
     
     
     
     Shiomoto                 Expires October 2007                  [Page 9]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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 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,
     
     
     
     Shiomoto                 Expires October 2007                 [Page 10]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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 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 October 2007                 [Page 11]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        "0001": LSP is an RA and is only advertised into the IP network.
     
        "0010": LSP is an RA 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                                |
           ~                                                               ~
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     
     
     
     Shiomoto                 Expires October 2007                 [Page 12]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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. 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 October 2007                 [Page 13]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
     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 October 2007                 [Page 14]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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
     
     
     
     
     Shiomoto                 Expires October 2007                 [Page 15]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        it has chosen to establish an LSP to that LSR and plans to use the
        LSP as a TE link.
     
        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 October 2007                 [Page 16]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
     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 October 2007                 [Page 17]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        [RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)",     RFC
                  4204, October 2005.
     
        [MLN]     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).
     
     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
     
     
        Richard Rabbat
        Google Inc.
        Email: rabbat@alum.mit.edu
     
     
        Arthi Ayyangar
        Nuova Systems
        2600 San Tomas Expressway
        Santa Clara, CA 95051
        Email: arthi@nuovasystems.com
     
        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
     
     
     
     Shiomoto                 Expires October 2007                 [Page 18]


     Internet-Draft    draft-ietf-ccamp-lsp-hierarchy-bis-02      April 2007
     
     
        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
     
      Copyright Statement
     
        Copyright  (C) The IETF Trust (2007). 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 October 2007                 [Page 19]
     

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