doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5146.txt b/doc/rfc/rfc5146.txt
new file mode 100644
index 0000000..738835c
--- /dev/null
+++ b/doc/rfc/rfc5146.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                     K. Kumaki, Ed.
+Request for Comments: 5146                              KDDI Corporation
+Category: Informational                                       March 2008
+
+
+       Interworking Requirements to Support Operation of MPLS-TE
+                          over GMPLS Networks
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   Operation of a Multiprotocol Label Switching (MPLS) traffic
+   engineering (TE) network as a client network to a Generalized MPLS
+   (GMPLS) network has enhanced operational capabilities compared to
+   those provided by a coexistent protocol model (i.e., operation of
+   MPLS-TE over an independently managed transport layer).
+
+   The GMPLS network may be a packet or a non-packet network, and may
+   itself be a multi-layer network supporting both packet and non-packet
+   technologies.  An MPLS-TE Label Switched Path (LSP) originates and
+   terminates on an MPLS Label Switching Router (LSR).  The GMPLS
+   network provides transparent transport for the end-to-end MPLS-TE
+   LSP.
+
+   This document describes a framework and Service Provider requirements
+   for operating MPLS-TE networks over GMPLS networks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki                       Informational                      [Page 1]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+   2. Reference Model .................................................4
+   3. Detailed Requirements ...........................................5
+      3.1. End-to-End Signaling .......................................5
+      3.2. Triggered Establishment of GMPLS LSPs ......................5
+      3.3. Diverse Paths for End-to-End MPLS-TE LSPs ..................6
+      3.4. Advertisement of MPLS-TE Information via the GMPLS
+           Network ....................................................6
+      3.5. Selective Advertisement of MPLS-TE Information via
+           a Border Node ..............................................6
+      3.6. Interworking of MPLS-TE and GMPLS Protection ...............7
+      3.7. Independent Failure Recovery and Reoptimization ............7
+      3.8. Complexity and Risks .......................................7
+      3.9. Scalability Considerations .................................7
+      3.10. Performance Considerations ................................8
+      3.11. Management Considerations .................................8
+   4. Security Considerations .........................................8
+   5. Recommended Solution Architecture ...............................9
+      5.1. Use of Contiguous, Hierarchical, and Stitched LSPs ........10
+      5.2. MPLS-TE Control Plane Connectivity ........................10
+      5.3. Fast Reroute Protection ...................................10
+      5.4. GMPLS LSP Advertisement ...................................11
+      5.5. GMPLS Deployment Considerations ...........................11
+   6. Acknowledgments ................................................11
+   7. References .....................................................11
+      7.1. Normative References ......................................11
+      7.2. Informative References ....................................12
+   8. Contributors' Addresses ........................................13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki                       Informational                      [Page 2]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+1.  Introduction
+
+   Multiprotocol Label Switching traffic engineering (MPLS-TE) networks
+   are often deployed over transport networks such that the transport
+   networks provide connectivity between the Label Switching Routers
+   (LSRs) in the MPLS-TE network.  Increasingly, these transport
+   networks are operated using a Generalized Multiprotocol Label
+   Switching (GMPLS) control plane.  Label Switched Paths (LSPs) in the
+   GMPLS network provide connectivity as virtual data links advertised
+   as TE links in the MPLS-TE network.
+
+   GMPLS protocols were developed as extensions to MPLS-TE protocols.
+   MPLS-TE is limited to the control of packet switching networks, but
+   GMPLS can also control technologies at layers one and two.
+
+   The GMPLS network may be managed by an operator as a separate network
+   (as it may have been when it was under management plane control
+   before the use of GMPLS as a control plane), but optimizations of
+   management and operation may be achieved by coordinating the use of
+   the MPLS-TE and GMPLS networks and operating the two networks with a
+   close client/server relationship.
+
+   GMPLS LSP setup may be triggered by the signaling of MPLS-TE LSPs in
+   the MPLS-TE network so that the GMPLS network is reactive to the
+   needs of the MPLS-TE network.  The triggering process can be under
+   the control of operator policies without needing direct intervention
+   by an operator.
+
+   The client/server configuration just described can also apply in
+   migration scenarios for MPLS-TE packet switching networks that are
+   being migrated to be under GMPLS control.  [RFC5145] describes a
+   migration scenario called the Island Model.  In this scenario, groups
+   of nodes (islands) are migrated from the MPLS-TE protocols to the
+   GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the
+   sea).  This scenario can be effectively managed as a client/server
+   network relationship using the framework described in this document.
+
+   In order to correctly manage the dynamic interaction between the MPLS
+   and GMPLS networks, it is necessary to understand the operational
+   requirements and the control that the operator can impose.  Although
+   this problem is very similar to the multi-layer networks described in
+   [MLN-REQ], it must be noted that those networks operate GMPLS
+   protocols in both the client and server networks, which facilitates
+   smoother interworking.  Where the client network uses MPLS-TE
+   protocols over the GMPLS server network, there is a need to study the
+   interworking of the two protocol sets.
+
+
+
+
+
+Kumaki                       Informational                      [Page 3]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+   This document examines the protocol requirements for protocol
+   interworking to operate an MPLS-TE network as a client network over a
+   GMPLS server network, and provides a framework for such operations.
+
+1.1.  Terminology
+
+   Although this Informational document is not a protocol specification,
+   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] for clarity
+   of exposure of the requirements.
+
+2.  Reference Model
+
+   The reference model used in this document is shown in Figure 1.  It
+   can easily be seen that the interworking between MPLS-TE and GMPLS
+   protocols must occur on a node and not on a link.  Nodes on the
+   interface between the MPLS-TE and GMPLS networks must be responsible
+   for handling both protocol sets and for providing any protocol
+   interworking that is required.  We call these nodes Border Routers.
+
+       --------------    -------------------------    --------------
+      | MPLS Client  |  |   GMPLS Server Network  |  |  MPLS Client |
+      |   Network    |  |                         |  |    Network   |
+      |              |  |                         |  |              |
+      |     ----   --+--+--    -----   -----    --+--+--   ----     |
+      |    |    | |        |  |     | |     |  |        | |    |    |
+      |    |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS|    |
+      |    |LSR | | Router |  | LSR | | LSR |  | Router | |LSR |    |
+      |    |    | |        |  |     | |     |  |        | |    |    |
+      |     ----   --+--+--    -----   -----    --+--+--   ----     |
+      |              |  |                         |  |              |
+      |              |  |                         |  |              |
+       --------------    -------------------------    --------------
+
+             |         |         GMPLS LSP         |         |
+             |         |<------------------------->|         |
+             |                                               |
+             |<--------------------------------------------->|
+                           End-to-End MPLS-TE LSP
+
+         Figure 1.  Reference model of MPLS-TE/GMPLS interworking
+
+   MPLS-TE network connectivity is provided through a GMPLS LSP which is
+   created between Border Routers.  End-to-end connectivity between MPLS
+   LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP
+   that is carried across the MPLS-TE network by the GMPLS LSP using
+   hierarchical LSP techniques [RFC4206], LSP stitching segments
+
+
+
+Kumaki                       Informational                      [Page 4]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+   [RFC5150], or a contiguous LSP.  LSP stitching segments and
+   contiguous LSPs are only available where the GMPLS network is a
+   packet switching network.
+
+3.  Detailed Requirements
+
+   This section describes detailed requirements for MPLS-TE/GMPLS
+   interworking in support of the reference model shown in Figure 1.
+
+   The functional requirements for GMPLS-MPLS interworking described in
+   this section must be met by any device participating in the
+   interworking.  This may include routers, servers, network management
+   devices, path computation elements, etc.
+
+3.1.  End-to-End Signaling
+
+   The solution MUST be able to preserve MPLS signaling information
+   signaled within the MPLS-TE client network at the start of the MPLS-
+   TE LSP and deliver it on the other side of the GMPLS server network
+   for use within the MPLS-TE client network at the end of the MPLS-TE
+   LSP.  This may require protocol mapping (and re-mapping), protocol
+   tunneling, or the use of remote protocol adjacencies.
+
+3.2.  Triggered Establishment of GMPLS LSPs
+
+   The solution MUST provide the ability to establish end-to-end MPLS-TE
+   LSPs over a GMPLS server network.  It SHOULD be possible for GMPLS
+   LSPs across the core network to be set up between Border Routers
+   triggered by the signaling of MPLS-TE LSPs in the client network, and
+   in this case, policy controls MUST be made available at the border
+   routers so that the operator of the GMPLS network can manage how core
+   network resources are utilized.  GMPLS LSPs MAY also be pre-
+   established as the result of management plane control.
+
+   Note that multiple GMPLS LSPs may be set up between a given pair of
+   Border Routers in support of connectivity in the MPLS client network.
+   If these LSPs are advertised as TE links in the client network, the
+   use of link bundling [RFC4201] can reduce any scaling concerns
+   associated with the advertisements.
+
+   The application of the Path Computation Element (PCE) [RFC4655] in
+   the context of an inter-layer network [PCE-INT] may be considered to
+   determine an end-to-end LSP with triggered GMPLS segment or tunnel.
+
+
+
+
+
+
+
+
+Kumaki                       Informational                      [Page 5]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+3.3.  Diverse Paths for End-to-End MPLS-TE LSPs
+
+   The solution SHOULD provide the ability to establish end-to-end
+   MPLS-TE LSPs having diverse paths for protection of the LSP traffic.
+   This means that MPLS-TE LSPs SHOULD be kept diverse both within the
+   client MPLS-TE network and as they cross the server GMPLS network.
+   This means that there SHOULD be a mechanism to request the provision
+   of diverse GMPLS LSPs between a pair of Border Routers to provide
+   protection of the GMPLS span, but also that there SHOULD be a way to
+   keep GMPLS LSPs between different Border Routers disjoint.
+
+3.4.  Advertisement of MPLS-TE Information via the GMPLS Network
+
+   The solution SHOULD provide the ability to exchange advertisements of
+   TE information between MPLS-TE client networks across the GMPLS
+   server network.
+
+   The advertisement of TE information from within an MPLS-TE client
+   network to all LSRs in the client network enables a head-end LSR to
+   compute an optimal path for an LSP to a tail-end LSR that is reached
+   over the GMPLS server network.
+
+   Where there is more than one client MPLS-TE network, the TE
+   information from separate MPLS-TE networks MUST be kept private,
+   confidential and secure.
+
+3.5.  Selective Advertisement of MPLS-TE Information via a Border Node
+
+   The solution SHOULD provide the ability to distribute TE reachability
+   information from the GMPLS server network to MPLS-TE networks
+   selectively.  This information is useful for the LSRs in the MPLS-TE
+   networks to compute paths that cross the GMPLS server network and to
+   select the correct Border Routers to provide connectivity.
+
+   The solution MUST NOT distribute TE information from within a non-PSC
+   (Packet Switch Capable) GMPLS server network to any client MPLS-TE
+   network as that information may cause confusion and selection of
+   inappropriate paths.
+
+   The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS
+   networks supporting PSC MPLS networks.
+
+
+
+
+
+
+
+
+
+
+Kumaki                       Informational                      [Page 6]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+3.6.  Interworking of MPLS-TE and GMPLS Protection
+
+   If an MPLS-TE LSP is protected using MPLS Fast Reroute (FRR)
+   [RFC4090], then similar protection MUST be provided over the GMPLS
+   island.  Operator and policy controls SHOULD be made available at the
+   Border Router to determine how suitable protection is provided in the
+   GMPLS island.
+
+3.7.  Independent Failure Recovery and Reoptimization
+
+   The solution SHOULD provide failure recovery and reoptimization in
+   the GMPLS server network without impacting the MPLS-TE client network
+   and vice versa.  That is, it SHOULD be possible to recover from a
+   fault within the GMPLS island or to reoptimize the path across the
+   GMPLS island without requiring signaling activity within the MPLS-TE
+   client network.  Similarly, it SHOULD be possible to perform recovery
+   or reoptimization within the MPLS-TE client network without requiring
+   signaling activity within the GMPLS server networks.
+
+   If a failure in the GMPLS server network can not be repaired
+   transparently, some kind of notification of the failure SHOULD be
+   transmitted to MPLS-TE network.
+
+3.8.  Complexity and Risks
+
+   The solution SHOULD NOT introduce unnecessary complexity to the
+   current operating network to such a degree that it would affect the
+   stability and diminish the benefits of deploying such a solution in
+   service provider networks.
+
+3.9.  Scalability Considerations
+
+   The solution MUST scale well with consideration to at least the
+   following metrics.
+
+   - The number of GMPLS-capable nodes (i.e., the size of the GMPLS
+     server network).
+
+   - The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE
+     client network).
+
+   - The number of MPLS-TE client networks.
+
+   - The number of GMPLS LSPs.
+
+   - The number of MPLS-TE LSPs.
+
+
+
+
+
+Kumaki                       Informational                      [Page 7]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+3.10.  Performance Considerations
+
+   The solution SHOULD be evaluated with regard to the following
+   criteria.
+
+   - Failure and restoration time.
+
+   - Impact and scalability of the control plane due to added overheads.
+
+   - Impact and scalability of the data/forwarding plane due to added
+     overheads.
+
+3.11.  Management Considerations
+
+   Manageability of the deployment of an MPLS-TE client network over
+   GMPLS server network MUST addresses the following considerations.
+
+   - Need for coordination of MIB modules used for control plane
+     management and monitoring in the client and server networks.
+
+   - Need for diagnostic tools that can discover and isolate faults
+     across the border between the MPLS-TE client and GMPLS server
+     networks.
+
+4.  Security Considerations
+
+   Border routers in the model described in this document are present on
+   administrative domain boundaries.  That is, the administrative
+   boundary does not lie on a link as it might in the inter-Autonomous-
+   System (inter-AS) case seen in IP networks.  Thus, many security
+   concerns for the inter-domain exchange of control plane messages do
+   not arise in this model -- the border router participates fully in
+   both the MPLS and the GMPLS network and must participate in the
+   security procedures of both networks.  Security considerations for
+   MPLS-TE and GMPLS protocols are discussed in [SECURITY].
+
+   However, policy considerations at the border routers are very
+   important and may be considered to form part of the security of the
+   networks.  In particular, the server network (the GMPLS network) may
+   wish to protect itself from behavior in the client network (such as
+   frequent demands to set up and tear down server LSPs) by appropriate
+   policies implemented at the border routers.  It should be observed
+   that, because the border routers form part of both networks, they are
+   trusted in both networks, and policies configured (whether locally or
+   centrally) for use by a border router are expected to be observed.
+
+   Nevertheless, authentication and access controls for operators will
+   be particularly important at border routers.  Operators of the client
+
+
+
+Kumaki                       Informational                      [Page 8]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+   MPLS-TE network MUST NOT be allowed to configure the server GMPLS
+   network (including setting server network policies), and operators of
+   the server GMPLS network MUST NOT be able configure the client MPLS-
+   TE network.  Obviously, it SHOULD be possible to grant an operator
+   privileges in both networks.  It may also be desirable to give
+   operators of one network access to (for example) status information
+   about the other network.
+
+   Mechanisms for authenticating operators and providing access controls
+   are not part of the responsibilities of the GMPLS protocol set, and
+   will depend on the management plane protocols and techniques
+   implemented.
+
+5.  Recommended Solution Architecture
+
+   The recommended solution architecture to meet the requirements set
+   out in Section 3 is known as the Border Peer Model.  This
+   architecture is a variant of the Augmented Model described in
+   [RFC3945].  The remainder of this document presents an overview of
+   this architecture.
+
+   In the Augmented Model, routing information from the lower layer
+   (server) network is filtered at the interface to the higher layer
+   (client) network and a subset of the information is distributed
+   within the higher layer network.
+
+   In the Border Peer Model, the interface between the client and server
+   networks is the Border Router.  This router has visibility of the
+   routing information in the server network yet also participates as a
+   peer in the client network.  Thus, the Border Router has full
+   visibility into both networks.  However, the Border Router does not
+   distribute server routing information into the client network, nor
+   does it distribute client routing information into the server
+   network.
+
+   The Border Peer Model may also be contrasted with the Overlay Model
+   [RFC3945].  In this model there is a protocol request/response
+   interface (the user network interface (UNI)) between the client and
+   server networks.  [RFC4208] shows how this interface may be supported
+   by GMPLS protocols operated between client edge and server edge
+   routers while retaining the routing information within the server
+   network.  That is, in the Overlay Model there is no exchange of
+   routing or reachability information between client and server
+   networks, and no network element has visibility into both client and
+   server networks.  The Border Peer Model can be viewed as placing the
+   UNI within the Border Router thus giving the Border Router peer
+   capabilities in both the client and server network.
+
+
+
+
+Kumaki                       Informational                      [Page 9]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+5.1.  Use of Contiguous, Hierarchical, and Stitched LSPs
+
+   All three LSP types MAY be supported in the Border Peer Model, but
+   contiguous LSPs are the hardest to support because they require
+   protocol mapping between the MPLS-TE client network and the GMPLS
+   server network.  Such protocol mapping can be achieved currently
+   since MPLS-TE signaling protocols are a subset of GMPLS, but this
+   mechanism is not future-proofed.
+
+   Contiguous and stitched LSPs can only be supported where the GMPLS
+   server network has the same switching type (that is, packet
+   switching) as the MPLS-TE network.  Requirements for independent
+   failure recovery within the GMPLS island require the use of loose
+   path reoptimization techniques [RFC4736] and end-to-end make-before-
+   break [RFC3209], which will not provide rapid recovery.
+
+   For these reasons, the use of hierarchical LSPs across the server
+   network is RECOMMENDED for the Border Peer Model, but see the
+   discussion of Fast Reroute protection in Section 5.3.
+
+5.2.  MPLS-TE Control Plane Connectivity
+
+   Control plane connectivity between MPLS-TE LSRs connected by a GMPLS
+   island in the Border Peer Model MAY be provided by the control
+   channels of the GMPLS network.  If this is done, a tunneling
+   mechanism (such as GRE [RFC2784]) SHOULD be used to ensure that
+   MPLS-TE information is not consumed by the GMPLS LSRs.  But care is
+   required to avoid swamping the control plane of the GMPLS network
+   with MPLS-TE control plane (particularly routing) messages.
+
+   In order to ensure scalability, control plane messages for the MPLS-
+   TE client network MAY be carried between Border Routers in a single
+   hop MPLS-TE LSP routed through the data plane of the GMPLS server
+   network.
+
+5.3.  Fast Reroute Protection
+
+   If the GMPLS network is packet switching, Fast Reroute protection can
+   be offered on all hops of a contiguous LSP.  If the GMPLS network is
+   packet switching then all hops of a hierarchical GMPLS LSP or GMPLS
+   stitching segment can be protected using Fast Reroute.  If the end-
+   to-end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet
+   switching network SHOULD provide such protection.
+
+   However, note that it is not possible to provide FRR node protection
+   of the upstream Border Router without careful consideration of
+   available paths, and protection of the downstream Border Router is
+   not possible where hierarchical LSPs or stitching segments are used.
+
+
+
+Kumaki                       Informational                     [Page 10]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+   Note further that Fast Reroute is not available in non-packet
+   technologies.  However, other protection techniques are supported by
+   GMPLS for non-packet networks and are likely to provide similar
+   levels of protection.
+
+   The limitations of FRR need careful consideration by the operator and
+   may lead to the decision to provide end-to-end protection for the
+   MPLS-TE LSP.
+
+5.4.  GMPLS LSP Advertisement
+
+   In the Border Peer Model, the LSPs established by the Border Routers
+   in the GMPLS server network SHOULD be advertised in the MPLS-TE
+   client network as real or virtual links.  In case real links are
+   advertised into the MPLS-TE client network, the Border Routers in the
+   MPLS-TE client network MAY establish IGP neighbors.  The Border
+   Routers MAY automatically advertise the GMPLS LSPs when establishing
+   them.
+
+5.5.  GMPLS Deployment Considerations
+
+   The Border Peer Model does not require the existing MPLS-TE client
+   network to be GMPLS aware and does not affect the operation and
+   management of the existing MPLS-TE client network.  Only border
+   routers need to be upgraded with the GMPLS functionality.  In this
+   fashion, the Border Peer Model renders itself for incremental
+   deployment of the GMPLS server network, without requiring
+   reconfiguration of existing areas/ASs, changing operation of IGP and
+   BGP or software upgrade of the existing MPLS-TE client network.
+
+6.  Acknowledgments
+
+   The author would like to express thanks to Raymond Zhang, Adrian
+   Farrel, and Deborah Brungard for their helpful and useful comments
+   and feedback.
+
+7.  References
+
+7.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.
+
+
+
+
+
+Kumaki                       Informational                     [Page 11]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+   [RFC3945]   Mannie, E., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+   [RFC4090]   Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
+               Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+               May 2005.
+
+   [RFC4201]   Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+               in MPLS Traffic Engineering (TE)", RFC 4201, 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.
+
+   [RFC5150]    Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+               "Label Switched Path Stitching with Generalized
+               Multiprotocol Label Switching Traffic Engineering (GMPLS
+               TE)", RFC 5150, February 2008.
+
+7.2.  Informative References
+
+   [RFC2784]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+               Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+               March 2000.
+
+   [RFC4655]   Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+               Computation Element (PCE)-Based Architecture", RFC 4655,
+               August 2006.
+
+   [RFC4736]   Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
+               "Reoptimization of Multiprotocol Label Switching (MPLS)
+               Traffic Engineering (TE) Loosely Routed Label Switched
+               Path (LSP)", RFC 4736, November 2006.
+
+   [RFC5145]   Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS
+               Migration", RFC 5145, March 2008.
+
+
+
+
+
+
+
+Kumaki                       Informational                     [Page 12]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+   [MLN-REQ]   Shiomoto, K., Papadimitriou, D., Le Roux, J.L.,
+               Vigoureux, M., and D. Brungard, "Requirements for GMPLS-
+               Based Multi-Region and Multi-Layer Networks (MRN/MLN)",
+               Work in Progress, January 2008.
+
+   [PCE-INT]   Oki, E., Le Roux , J-L., and A. Farrel, "Framework for
+               PCE-Based Inter-Layer MPLS and GMPLS Traffic
+               Engineering," Work in Progress, January 2008.
+
+   [SECURITY]  Fang, L., "Security Framework for MPLS and GMPLS
+               Networks", Work in Progress, November 2007.
+
+8.  Contributors' Addresses
+
+   Tomohiro Otani
+   KDDI R&D Laboratories, Inc.
+   2-1-15 Ohara Kamifukuoka
+   Saitama, 356-8502, Japan
+
+   Phone:  +81-49-278-7357
+   EMail:  otani@kddilabs.jp
+
+
+   Shuichi Okamoto
+   NICT JGN II Tsukuba Reserach Center
+   1-8-1, Otemachi Chiyoda-ku,
+   Tokyo, 100-0004, Japan
+
+   Phone: +81-3-5200-2117
+   EMail: okamoto-s@nict.go.jp
+
+
+   Kazuhiro Fujihara
+   NTT Communications Corporation
+   Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
+   Tokyo 163-1421, Japan
+
+   EMail: kazuhiro.fujihara@ntt.com
+
+
+   Yuichi Ikejiri
+   NTT Communications Corporation
+   Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
+   Tokyo 163-1421, Japan
+
+   EMail: y.ikejiri@ntt.com
+
+
+
+
+
+Kumaki                       Informational                     [Page 13]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+Editor's Address
+
+   Kenji Kumaki
+   KDDI Corporation
+   Garden Air Tower
+   Iidabashi, Chiyoda-ku,
+   Tokyo, 102-8460, JAPAN
+
+   EMail: ke-kumaki@kddi.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki                       Informational                     [Page 14]
+
+RFC 5146         Operating MPLS-TE over GMPLS Networks        March 2008
+
+
+Full 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki                       Informational                     [Page 15]
+