draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt   draft-ietf-ccamp-mpls-gmpls-interwork-reqts-03.txt 
Network Working Group K. Kumaki, Ed. Network Working Group K. Kumaki, Ed.
Internet Draft KDDI Corporation Internet Draft KDDI Corporation
Intended Status: Informational Intended Status: Informational
Created: September 24, 2007 Created: November 5, 2007
Expires: March 24, 2008 Expires: May 5, 2008
Interworking Requirements to Support operation of MPLS-TE over GMPLS Interworking Requirements to Support operation of MPLS-TE over GMPLS
Networks Networks
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt draft-ietf-ccamp-mpls-gmpls-interwork-reqts-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Operation of an 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 (ships in the night). those provided by a co-existent 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 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. A 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 network
provides transparent transport for the end-to-end MPLS-TE LSP. provides transparent transport for the end-to-end MPLS-TE LSP.
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1 Terminology................................................3 1.1 Terminology................................................3
2. Reference model................................................4 2. Reference model................................................4
3. Detailed Requirements..........................................4 3. Detailed Requirements..........................................4
3.1 End-to-End Signaling.......................................5 3.1 End-to-End Signaling.......................................5
skipping to change at page 2, line 30 skipping to change at page 2, line 28
3.5 Selective Advertisement of MPLS-TE Information via a Border 3.5 Selective Advertisement of MPLS-TE Information via a Border
Node...........................................................5 Node...........................................................5
3.6 Interworking of MPLS-TE and GMPLS Protection...............6 3.6 Interworking of MPLS-TE and GMPLS Protection...............6
3.7 Independent Failure Recovery and Reoptimization............6 3.7 Independent Failure Recovery and Reoptimization............6
3.8 Complexity and Risks.......................................6 3.8 Complexity and Risks.......................................6
3.9 Scalability Considerations.................................6 3.9 Scalability Considerations.................................6
3.10 Performance Considerations................................7 3.10 Performance Considerations................................7
3.11 Management Considerations.................................7 3.11 Management Considerations.................................7
4. Security Considerations........................................7 4. Security Considerations........................................7
5. Recommended Solution Architecture..............................8 5. Recommended Solution Architecture..............................8
5.1 Use of Contiguous, Hierarchical, and Stitched LSPs.........8 5.1 Use of Contiguous, Hierarchical, and Stitched LSPs.........9
5.2 MPLS-TE Control Plane Connectivity.........................9 5.2 MPLS-TE Control Plane Connectivity.........................9
5.3 Fast Reroute Protection....................................9 5.3 Fast Reroute Protection....................................9
5.4 GMPLS LSP Advertisement....................................9 5.4 GMPLS LSP Advertisement...................................10
5.5 GMPLS Deployment Considerations...........................10 5.5 GMPLS Deployment Considerations...........................10
6. IANA Considerations...........................................10 6. IANA Considerations...........................................10
7. Acknowledgments...............................................10 7. Acknowledgments...............................................10
8. References....................................................10 8. References....................................................10
8.1 Normative References......................................10 8.1 Normative References......................................10
8.2 Informative References....................................11 8.2 Informative References....................................11
9. Author's Address..............................................11 9. Author's Address..............................................11
10. Contributors' Addresses......................................11 10. Contributors' Addresses......................................12
11. Intellectual Property Statement..............................12 11. Intellectual Property Statement..............................12
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 networks
are operated using a Generalized Multiprotocol Label Switching are operated using a Generalized Multiprotocol Label Switching
(GMPLS) control plane, and label Switched Paths (LSPs) in the GMPLS (GMPLS) control plane, and label Switched Paths (LSPs) in the GMPLS
network provide connectivity as virtual data links advertised as TE network provide connectivity as virtual data links advertised as TE
links in the MPLS-TE network. links in the MPLS-TE network.
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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.
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.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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-02 September 2007
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 5, line 5 skipping to change at page 5, line 5
hierarchical LSP techniques [RFC4206], LSP stitching segments hierarchical LSP techniques [RFC4206], LSP stitching segments
[STITCH], or a contiguous LSP. LSP stitching segments and contiguous [STITCH], or a contiguous LSP. LSP stitching segments and contiguous
LSPs are only available where the GMPLS network is a packet switching LSPs are only available where the GMPLS network is a packet switching
network. network.
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.
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
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
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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
GMPLS server network to any client MPLS-TE network as that (Packet Switch Capable) GMPLS server network to any client MPLS-TE
information may cause confusion and selection of inappropriate paths. network as that information may cause confusion and selection of
inappropriate paths.
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
skipping to change at page 6, line 53 skipping to change at page 7, line 4
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).
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
- 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.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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.
4. Security Considerations 4. Security Considerations
Security issues for this model relate to control and data planes, and Border routers in the model described in this document are present on
to authentication at border routers. Actually, border routers are administrative domain boundaries. That is, the administrative
administrative boundaries. Therefore, if the MPLS-TE client network boundary does not lie on a link as it might in the inter-Autonomous
and GMPLS server network are in completely different administrations, System case seen in IP networks. Thus, many security concerns for the
some functions for limiting control and data packet exchanges at the inter-domain exchange of control plane messages do not arise in this
domain boundary are required. 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].
Authentication mechanisms to separate operators in the MPLS-TE client However, policy considerations at the border routers are very
network from operators in the GMPLS server network are also required important and may be considered to form part of the security of the
in the border routers. In this case, operators in the MPLS-TE client networks. In particular, the server network (the GMPLS network) may
network MUST NOT be allowed to configure the GMPLS server network, wish to protect itself from behavior in the client network (such as
and vice versa. But, in some cases, both types of operator MAY check frequent demands to set up and tear down server LSPs) by appropriate
the state of both networks. 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.
On the other hand, if the MPLS-TE client and GMPLS server network are Nevertheless, authentication and access controls for operators will
part of the same administration, functions for limiting control and be particularly important at border routers. Operators of the client
data packet exchange are not required. Also, authentication MPLS-TE network MUST NOT be allowed to configure the server GMPLS
mechanisms to separate operators in the MPLS-TE client network from network (including setting server network policies), and operators of
operators in the GMPLS server network in border routers are not the server GMPLS network MUST NOT be able configure the client MPLS-
required. But, in some cases, loose restriction at command and TE network. Obviously, it SHOULD be possible to grant an operator
configuration levels MAY exist between operators in the MPLS-TE privileges in both networks. It may also be desirable to give
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 operators of one network access to (for example) status information
about the other network.
client network and operators in the GMPLS server network. Mechanisms for authenticating operators and providing access controls
do not form part of the responsibilities of the GMPLS protocol set,
and will depend on the management plane protocols and techniques
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 architecture
is a variant of the Augmented Model described in [RFC3945]. The is a variant of the Augmented Model described in [RFC3945]. The
remainder of this document presents an overview of this architecture. 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.
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
skipping to change at page 9, line 4 skipping to change at page 9, line 18
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 since
MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism
is not future-proofed. 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
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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
skipping to change at page 10, line 4 skipping to change at page 10, line 18
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
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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 on the operation and
skipping to change at page 11, line 5 skipping to change at page 11, line 19
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC3945, October 2004. (GMPLS) Architecture", RFC3945, October 2004.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) [RFC4206] Kompella, K., and Rekhter, Y., "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.
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
[RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label
Switching (GMPLS) User-Network Interface (UNI): Resource Switching (GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) Support ReserVation Protocol-Traffic Engineering (RSVP-TE) Support
for the Overlay Model", RFC 4208, October 2005. for the Overlay Model", RFC 4208, October 2005.
[STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching
with Generalized MPLS Traffic Engineering", draft-ietf- with Generalized MPLS Traffic Engineering", draft-ietf-
ccamp-lsp-stitching, work in progress. ccamp-lsp-stitching, work in progress.
8.2 Informative References 8.2 Informative References
skipping to change at page 11, line 30 skipping to change at page 11, line 42
[RFC4736] Vasseur, JP., Ikejiri, Y., and Zhang, R., "Reoptimization [RFC4736] Vasseur, JP., Ikejiri, Y., and Zhang, R., "Reoptimization
of Multiprotocol Label Switching (MPLS) Traffic Engineering of Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) loosely routed Label Switch Path (LSP)", RFC4736, (TE) loosely routed Label Switch Path (LSP)", RFC4736,
November 2006. November 2006.
[MIGRATE] Shiomoto, K., et al., "Framework for MPLS-TE to GMPLS [MIGRATE] Shiomoto, K., et al., "Framework for MPLS-TE to GMPLS
migration", draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, migration", draft-ietf-ccamp-mpls-gmpls-interwork-fmwk,
work in progress. work in progress.
[MLN] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, [MLN] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M.,
M., Brungard, D., "Requirements for GMPLS-based multi- Brungard, D., "Requirements for GMPLS-based multi-region and
region and multi-layer networks (MRN/MLN)", draft-ietf- multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-
ccamp-gmpls-mln-reqs, work in progress. reqs, work in progress.
[SECURITY] Fang, L., "Security Framework for MPLS and GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework, work in
progress.
9. Author's Address 9. Author's Address
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
Iidabashi, Chiyoda-ku, Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
skipping to change at page 12, line 4 skipping to change at page 12, line 21
Tomohiro Otani Tomohiro Otani
KDDI R&D Laboratories, Inc. KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357
Saitama, 356-8502. Japan Email: otani@kddilabs.jp Saitama, 356-8502. Japan 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, Phone : +81-3-5200-2117 1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117
Tokyo, 100-0004, Japan E-mail :okamoto-s@nict.go.jp Tokyo, 100-0004, Japan E-mail :okamoto-s@nict.go.jp
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
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 Tokyo 163-1421, Japan
EMail: kazuhiro.fujihara@ntt.com 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
skipping to change at page 13, line 5 skipping to change at page 13, line 22
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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.
 End of changes. 26 change blocks. 
59 lines changed or deleted 53 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/