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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/