summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5146.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5146.txt')
-rw-r--r--doc/rfc/rfc5146.txt843
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]
+