TEAS Working Group                                         F. Zhang, Ed.
Internet-Draft                                                    Huawei
Intended status: Standards Track                O. Gonzalez de Dios, Ed.
Expires: December 14, 25, 2015                         Telefonica Global CTO
                                                                   D. Li
                                                                  Huawei
                                                             C. Margaria
                                                              M. Hartley
                                                                  Z. Ali
                                                                   Cisco
                                                             C. Margaria

                                                           June 12, 25, 2015

           RSVP-TE Extensions for Collecting SRLG Information
                draft-ietf-teas-rsvp-te-srlg-collect-01
                draft-ietf-teas-rsvp-te-srlg-collect-02

Abstract

   This document provides extensions for the Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) to support automatic
   collection of Shared Risk Link Group (SRLG) information for the TE
   link formed by a Label Switched Path (LSP).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 14, 25, 2015.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Applicability Example: Dual Homing  . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  RSVP-TE Requirements  . . . . . . . . . . . . . . . . . . . .   5
     3.1.  SRLG Collection Indication  . . . . . . . . . . . . . . .   5
     3.2.  SRLG Collection . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  SRLG Update . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Encodings . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  SRLG Collection Flag  . . . . . . . . . . . . . . . . . .   5
     4.2.  RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . . .   6
   5.  Signaling Procedures  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  SRLG Collection . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  SRLG Update . . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Compatibility . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
     6.1.  Policy Configuration  . . . . . . . . . . . . . . . . . .   9
     6.2.  Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  RSVP Attribute Bit Flags  . . . . . . . . . . . . . . . .  10
     8.2.  ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . .  11
     8.3.  Policy Control Failure Error subcodes . . . . . . . . . .  11
   9.  Acknowledgements  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   It is important to understand which TE links in the network might be
   at risk from the same failures.  In this sense, a set of links can
   constitute a 'shared risk link group' (SRLG) if they share a resource
   whose failure can affect all links in the set [RFC4202].

   On the other hand, as described in [RFC4206] and [RFC6107], H-LSP
   (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying
   one or more other LSPs.  Both of the H-LSP and S-LSP can be formed as
   a TE link.  In such cases, it is important to know the SRLG
   information of the LSPs that will be used to carry further LSPs.

   This document provides a mechanism to collect the SRLGs used by a
   LSP, which can then be advertized as properties of the TE-link formed
   by that LSP.  Note that specification of the the use of the collected
   SRLGs is outside the scope of this document.

1.1.  Applicability Example: Dual Homing

   An interesting use case for the SRLG collection procedures defined in
   this document is achieving LSP diversity in a dual homing scenario.
   The use case is illustrated in Figure 1, when the overlay model is
   applied as defined in RFC 4208 [RFC4208] . In this example, the
   exchange of routing information over the User-Network Interface (UNI)
   is prohibited by operator policy.

                            +---+    +---+
                            | P |....| P |
                            +---+    +---+
                           /              \
                      +-----+               +-----+
             +---+    | PE1 |               | PE3 |    +---+
             |CE1|----|     |               |     |----|CE2|
             +---+\   +-----+               +-----+   /+---+
                   \     |                     |     /
                    \ +-----+               +-----+ /
                     \| PE2 |               | PE4 |/
                      |     |               |     |
                      +-----+               +-----+
                            \              /
                            +---+    +---+
                            | P |....| P |
                            +---+    +---+

                    Figure 1: Dual Homing Configuration

   Single-homed customer edge (CE) devices are connected to a single
   provider edge (PE) device via a single UNI link (which could be a
   bundle of parallel links, typically using the same fiber cable). This
   single UNI link can constitute a single point of failure.  Such a
   single point of failure can be avoided if the CE device is connected
   to two PE devices via two UNI interfaces as depicted in Figure 1
   above for CE1 and CE2, respectively.

   For the dual-homing case, it is possible to establish two connections
   (LSPs) from the source CE device to the same destination CE device
   where one connection is using one UNI link to PE1, for example, and
   the other connection is using the UNI link to PE2.  In order to avoid
   single points of failure within the provider network, it is necessary
   to also ensure path (LSP) diversity within the provider network in
   order to achieve end-to-end diversity for the two LSPs between the
   two CE devices CE1 and CE2.  This use case describes how it is
   possible to achieve path diversity within the provider network based
   on collected SRLG information.  As the two connections (LSPs) enter
   the provider network at different PE devices, the PE device that
   receives the connection request for the second connection needs to
   know the additional path computation constraints such that the path
   of the second LSP is disjoint with respect to the already established
   first connection.

   As SRLG information is normally not shared between the provider
   network and the client network, i.e., between PE and CE devices, the
   challenge is how to solve the diversity problem when a CE is dual-
   homed.  For example, CE1 in Figure 1 may have requested an LSP1 to
   CE2 via PE1 that is routed via PE3 to CE2.  CE1 can then subsequently
   request an LSP2 to CE2 via PE2 with the constraint that it needs to
   be maximally SRLG disjoint with respect to LSP1.  PE2, however, does
   not have any SRLG information associated with LSP1, which is needed
   as input for its constraint-based path computation function.  If CE1
   is capable of retrieving the SRLG information associated with LSP1
   from PE1, it can pass this information to PE2 as part of the LSP2
   setup request (RSVP PATH message), and PE2 can now calculate a path
   for LSP2 that is SRLG disjoint with respect to LSP1.  The SRLG
   information associated with LSP1 can already be retrieved when LSP1
   is setup or at any time before LSP2 is setup.

   The RSVP extensions for collecting SRLG information defined in this
   document make it possible to retrieve SRLG information for an LSP and
   hence solve the dual-homing LSP diversity problem.  When CE1 sends
   the setup request for LSP2 to PE2, it can also request the collection
   of SRLG information for LSP2 and send that information to PE1.  This
   will ensure that the two paths for the two LSPs remain mutually
   diverse, which is important, when the provider network is capable to
   restore connections that failed due to a network failure (fiber cut)
   in the provider network.

   Note that the knowledge of SRLG information even for multiple LSPs
   does not allow a CE devices to derive the provider network topology
   based on the collected SRLG information.

2.  Requirements Language

   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 RFC 2119 [RFC2119].

3.  RSVP-TE Requirements

3.1.  SRLG Collection Indication

   The ingress node of the LSP SHOULD be capable of indicating whether
   the SRLG information of the LSP is to be collected during the
   signaling procedure of setting up an LSP.  SRLG information SHOULD
   NOT be collected without an explicit request for it being made by the
   ingress node.

3.2.  SRLG Collection

   If requested, the SRLG information SHOULD be collected during the
   setup of an LSP.  The endpoints of the LSP can use the collected SRLG
   information, for example, for routing, sharing and TE link
   configuration purposes.

3.3.  SRLG Update

   When the SRLG information of an existing LSP for which SRLG
   information was collected during signaling changes, the relevant
   nodes of the LSP SHOULD be capable of updating the SRLG information
   of the LSP.  This means that that the signaling procedure SHOULD be
   capable of updating the new SRLG information.

4.  Encodings

4.1.  SRLG Collection Flag

   In order to indicate nodes that SRLG collection is desired, this
   document defines a new flag in the Attribute Flags TLV (see RFC 5420
   [RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or
   LSP_ATTRIBUTES Object:

   o  Bit Number (temporarily 12, an early allocation has been made by
      IANA, see Section 8.1 for more details): SRLG Collection flag

   The SRLG Collection flag is meaningful on a Path message.  If the
   SRLG Collection flag is set to 1, it means that the SRLG information
   SHOULD be reported to the ingress and egress node along the setup of
   the LSP.

   The rules of the processing of the Attribute Flags TLV are not
   changed.

4.2.  RRO SRLG sub-object

   This document defines a new RRO sub-object (ROUTE_RECORD sub-object)
   to record the SRLG information of the LSP.  Its format is modeled on
   the RRO sub-objects defined in RFC 3209 [RFC3209].

       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     |     Length    |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 SRLG ID 1 (4 bytes)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ......                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 SRLG ID n (4 bytes)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

   The type of the sub-object.  The value is temporarily 34.  An early
   allocation has been made by IANA (see Section 8.2 for more details).

   Length

   The Length field contains the total length of the sub-object in
   bytes, including the Type and Length fields.  The Length depends on
   the number of SRLG IDs.

   Reserved

   This 2 byte field is reserved.  It SHOULD be set to zero on
   transmission and MUST be ignored on receipt.

   SRLG ID

   This 4 byte field contains one SRLG ID.  There is one SRLG ID field
   per SRLG collected.  There MAY be multiple SRLG ID fields in an SRLG
   sub-object

   As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is
   managed as a stack.  The SRLG sub-object SHOULD be pushed by the node
   before the node IP address or link identifier.  The SRLG-sub-object
   SHOULD be pushed after the Attribute subobject, if present, and after
   the LABEL subobject, if requested.

   RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub-
   object) in the RRO so as to facilitate confidentiality in the
   signaling of inter-domain TE LSPs, and allows the path segment that
   needs to be hidden (that is, a Confidential Path Segment (CPS)) to be
   replaced in the RRO with a PKS.  If the CPS contains SRLG Sub-
   objects, these MAY be retained in the RRO by adding them again after
   the PKS Sub-object in the RRO.  The CPS is defined in RFC 5520
   [RFC5520]

   A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without
   also pushing either a IPv4 sub-object, a IPv6 sub-object, a
   Unnumbered Interface ID sub-object or a Path Key sub-object.

   The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
   LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.

5.  Signaling Procedures

5.1.  SRLG Collection

   Per RFC 3209 [RFC3209], an ingress node initiates the recording of
   the route information of an LSP by adding a RRO to a Path message. If
   an ingress node also desires SRLG recording, it MUST set the SRLG
   Collection Flag in the Attribute Flags TLV which MAY be carried
   either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
   mandatory, or in an LSP_ATTRIBUTES Object when the collection is
   desired, but not mandatory mandatory.

   When a node receives a Path message which carries an
   LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag set, if
   local policy determines that the SRLG information is not to be
   provided to the endpoints, it MUST return a PathErr message with with:
   o  Error Code 2 (policy) and
   o  Error subcode "SRLG Recording Rejected" (value 31, an early
      allocation of the value has been done by IANA, see Section 8.3 for
      more details)
   to reject the Path message.

   When a node receives a Path message which carries an LSP_ATTRIBUTES
   Object and the SRLG Collection Flag set, if local policy determines
   that the SRLG information is not to be provided to the endpoints, the
   Path message SHOULD NOT be rejected due to SRLG recording restriction
   and the Path message SHOULD be forwarded without any SRLG sub-
   object(s) in the RRO of the corresponding outgoing Path message.

   If local policy permits the recording of the SRLG information, the
   processing node SHOULD add local SRLG information, as defined below,
   to the RRO of the corresponding outgoing Path message.  The
   processing node MAY add multiple SRLG sub-objects to the RRO if
   necesary.  It then forwards the Path message to the next node in the
   downstream direction.

   If the addition of SRLG information to the RRO would result in the
   RRO exceeding its maximum possible size or becoming too large for the
   Path message to contain it, the requested SRLGs MUST NOT be added. If
   the SRLG collection request was contained in an
   LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as
   specified by RFC 3209 [RFC3209] and drop the RRO from the Path
   message entirely.  If the SRLG collection request was contained in an
   LSP_ATTRIBUTES Object, the processing node MAY omit some or all of
   the requested SRLGs from the RRO; otherwise it MUST behave as
   specified by RFC 3209 [RFC3209] and drop the RRO from the Path
   message entirely.

   Following the steps described above, the intermediate nodes of the
   LSP can collect the SRLG information in the RRO during the processing
   of the Path message hop by hop.  When the Path message arrives at the
   egress node, the egress node receives SRLG information in the RRO.

   Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
   message which contains an RRO, an egress node initiates the RRO
   process by adding an RRO to the outgoing Resv message.  The
   processing for RROs contained in Resv messages then mirrors that of
   the Path messages.

   When a node receives a Resv message for an LSP for which SRLG
   Collection is specified, then when local policy allows recording SRLG
   information, the node SHOULD add SRLG information, to the RRO of the
   corresponding outgoing Resv message, as specified below.  When the
   Resv message arrives at the ingress node, the ingress node can
   extract the SRLG information from the RRO in the same way as the
   egress node.

   Note that a link's SRLG information for the upstream direction cannot
   be assumed to be the same as that in the downstream.

   o  For Path and Resv messages for a unidirectional LSP, a node SHOULD
      include SRLG sub-objects in the RRO for the downstream data link
      only.

   o  For Path and Resv messages for a bidirectional LSP, a node SHOULD
      include SRLG sub-objects in the RRO for both the upstream data
      link and the downstream data link from the local node.  In this
      case, the node MUST include the information in the same order for
      both Path messages and Resv messages.  That is, the SRLG sub-
      object for the upstream link is added to the RRO before the SRLG
      sub-object for the downstream link.

   Based on the above procedure, the endpoints can get the SRLG
   information automatically.  Then the endpoints can for instance
   advertise it as a TE link to the routing instance based on the
   procedure described in [RFC6107] and configure the SRLG information
   of the FA automatically.

5.2.  SRLG Update

   When the SRLG information of a link is changed, the LSPs using that
   link need to be aware of the changes.  The procedures defined in
   Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG
   information if the SRLG change is to be communicated to other nodes
   according to the local node's policy.  If local policy is that the
   SRLG change SHOULD be suppressed or would result in no change to the
   previously signaled SRLG-list, the node SHOULD NOT send an update.

5.3.  Compatibility

   A node that does not recognize the SRLG Collection Flag in the
   Attribute Flags TLV is expected to proceed as specified in RFC 5420
   [RFC5420].  It is expected to pass the TLV on unaltered if it appears
   in a LSP_ATTRIBUTES object, or reject the Path message with the
   appropriate Error Code and Value if it appears in a
   LSP_REQUIRED_ATTRIBUTES object.

   A node that does not recognize the SRLG RRO sub-object is expected to
   behave as specified in RFC 3209 [RFC3209]: unrecognized subobjects
   are to be ignored and passed on unchanged.

6.  Manageability Considerations

6.1.  Policy Configuration

   In a border node of inter-domain or inter-layer network, the
   following SRLG processing policy SHOULD be capable of being
   configured:

   o  Whether the SRLG IDs of the domain or specific layer network can
      be exposed to the nodes outside the domain or layer network, or
      whether they SHOULD be summarized, mapped to values that are
      comprehensible to nodes outside the domain or layer network, or
      removed entirely.

   A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy.

6.2.  Coherent SRLG IDs

   In a multi-layer multi-domain scenario, SRLG ids can be configured by
   different management entities in each layer/domain.  In such
   scenarios, maintaining a coherent set of SRLG IDs is a key
   requirement in order to be able to use the SRLG information properly.
   Thus, SRLG IDs SHOULD be unique.  Note that current procedure is
   targeted towards a scenario where the different layers and domains
   belong to the same operator, or to several coordinated administrative
   groups.  Ensuring the aforementioned coherence of SRLG IDs is beyond
   the scope of this document.

   Further scenarios, where coherence in the SRLG IDs cannot be
   guaranteed are out of the scope of the present document and are left
   for further study.

7.  Security Considerations

   This document builds on the mechanisms defined in [RFC3473], which
   also discusses related security measures.  In addition, [RFC5920]
   provides an overview of security vulnerabilities and protection
   mechanisms for the GMPLS control plane.  The procedures defined in
   this document permit the transfer of SRLG data between layers or
   domains during the signaling of LSPs, subject to policy at the layer
   or domain boundary.  It is recommended that domain/layer boundary
   policies take the implications of releasing SRLG information into
   consideration and behave accordingly during LSP signaling.

8.  IANA Considerations

8.1.  RSVP Attribute Bit Flags

   IANA has created a registry and manages the space of the Attribute
   bit flags of the Attribute Flags TLV, as described in section 11.3 of
   RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource
   Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters"
   registry located in http://www.iana.org/assignments/rsvp-te-
   parameters".  IANA has made an early allocation in the "Attribute
   Flags" section of the mentioned registry that expires on 2015-09-11.

   This document introduces a new Attribute Bit Flag:

        Bit No       Name        Attribute   Attribute   RRO  Reference
                                 Flags Path  Flags Resv
        -----------  ----------  ----------  ----------- ---  ---------
        12 (tempo-   SRLG        Yes         Yes         Yes  This I-D
        rary expires collection
        2015-09-11)  Flag

8.2.  ROUTE_RECORD Object

   IANA manages the "RSVP PARAMETERS" registry located at
   http://www.iana.org/assignments/rsvp-parameters.  IANA has made an
   early allocation in the Sub-object type 21 ROUTE_RECORD - Type 1
   Route Record registry.  The early allocation expires on 2015-09-11.

   This document introduces a new RRO sub-object:

             Value                    Description             Reference
             ---------------------    -------------------     ---------
             34 (temporary,           SRLG sub-object         This I-D
             expires 2015-09-11)

8.3.  Policy Control Failure Error subcodes

   IANA manages the assignments in the "Error Codes and Globally-Defined
   Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry
   located at http://www.iana.org/assignments/rsvp-parameters.  IANA has
   made an early allocation in the "Sub-Codes - 2 Policy Control
   Failure" subsection of the the "Error Codes and Globally-Defined
   Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. The
   early allocation expires on 2015-09-11.

   This document introduces a new Policy Control Failure Error sub-code:

             Value                   Description               Reference
             ---------------------   -----------------------   ---------
             21 (temporary,          SRLG Recording Rejected   This I-D
             expires 2015-09-11)

9.  Contributors

   Dan Li
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   P.R.China
   Email: danli@huawei.com

10.  Acknowledgements

   The authors would like to thank Igor Bryskin, Ramon Casellas, Lou
   Berger, Alan Davey, Dhruv Dhody and Dieter Beller for their useful
   comments and improvements to the this document.

10.

11.  References

10.1.
11.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.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, February 2009.

   [RFC5520]  Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
              Topology Confidentiality in Inter-Domain Path Computation
              Using a Path-Key-Based Mechanism", RFC 5520, April 2009.

   [RFC5553]  Farrel, A., Bradford, R., and JP. Vasseur, "Resource
              Reservation Protocol (RSVP) Extensions for Path Key
              Support", RFC 5553, May 2009.

10.2.

11.2.  Informative References

   [RFC4202]  Kompella, K. and Y. Rekhter, "Routing Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4202, October 2005.

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
              "Generalized Multiprotocol Label Switching (GMPLS) User-
              Network Interface (UNI): Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Support for the Overlay
              Model", RFC 4208, October 2005.

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6107]  Shiomoto, K. and A. Farrel, "Procedures for Dynamically
              Signaled Hierarchical Label Switched Paths", RFC 6107,
              February 2011.

Authors' Addresses
   Fatai Zhang (editor)
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   P.R.China
   Email: zhangfatai@huawei.com

   Oscar Gonzalez de Dios (editor)
   Telefonica Global CTO
   Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045
   Madrid  28050
   Spain
   Phone: +34 913129647
   Email: oscar.gonzalezdedios@telefonica.com

   Dan Li
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   P.R.China
   Email: danli@huawei.com

   Cyril Margaria
   Suite 4001, 200 Somerset Corporate Blvd.
   Bridgewater, NJ  08807
   US
   Email: cyril.margaria@gmail.com

   Matt Hartley
   Cisco
   Email: mhartley@cisco.com

   Zafar Ali
   Cisco
   Email: zali@cisco.com