Network Working Group
Internet Draft Kenji Kumaki
Category: Informational KDDI Corporation
Expires: December 27, 2006 Tomohiro Otani
KDDI R&D Labs
Shuichi Okamoto
NICT
Kazuhiro Fujihara
Yuichi Ikejiri
NTT
Communications
June 26, 2006
Requirements for MPLS-TE/GMPLS interworking
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
K.Kumaki et al. Expires - December 2006 [Page 1]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
This document describes Service Provider requirements for MPLS-
TE/GMPLS interworking.
The main objective is to allow the operation of an MPLS-TE network as
a client network over a GMPLS network. The GMPLS network may be a
packet or non-packet network.
Specification of solutions is out of scope for this document.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Problem Statement..............................................3
4. Reference model................................................4
5. Detailed Requirements..........................................4
5.1 Use of GMPLS optical network resources in MPLS-TE networks.5
5.2 Mapping signaling information between MPLS-TE and GMPLS....5
5.3 Establishment of GMPLS LSPs triggered by end-to-end MPLS-TE
LSPs signaling.................................................5
5.4 Establishment of end-to-end MPLS-TE LSPs having diverse paths
over GMPLS optical network.....................................5
5.5 Advertisement of TE information via GMPLS optical domain...5
5.6 Selective advertisement of TE information via a border node6
5.7 Interworking of MPLS-TE and GMPLS protection...............6
5.8 Failure recovery...........................................6
5.9 Complexity and Risks.......................................6
5.10 Scalability consideration.................................6
5.11 Performance consideration.................................7
5.12 Management consideration..................................7
6. Security Considerations........................................7
7. IANA Considerations............................................7
8. Normative References...........................................7
9 .Acknowledgments................................................8
10.Author's Addresses.............................................8
11.Intellectual Property Statement................................8
1. Introduction
Recently, the deployment of a GMPLS network is planned or under
investigation among many service providers, and some of very advanced
K.Kumaki, et al. Expires December 27, 2006 [Page 2]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
research networks have already been operated based on GMPLS
technology. GMPLS is developed as an extension of MPLS-TE and allows
control a transport network consisting of TDM cross-connect,
optical/lambda switches, and fibers. By introducing GMPLS technology,
some service providers expect that MPLS-TE network connectivity is
effectively and reliably established over the GMPLS network. If MPLS-
TE and GMPLS protocols can interwork with each other, the
introduction of GMPLS would be more beneficial for service providers,
because this is expected to improve the resource utilization, network
resiliency and manageability all over the network, less impacting the
existing MPLS-TE networks.
Currently, there is no clear definition and standardization work to
interwork between MPLS-TE routers and GMPLS routers or switches, i.e.
, between MPLS-TE networks and GMPLS networks. In order to accelerate
the deployment of GMPLS technology, MPLS-TE/GMPLS interworking is a
key.
In order to create the definition of MPLS-TE/GMPLS interworking
technology, the concrete requirement is preferably defined from the
point of operational experience of MPLS-TE/GMPLS networks and future
view on these technologies by collecting the input and requirements
from various service providers.
Considering such environment, this document focuses on the
requirement of MPLS-TE/GMPLS interworking especially in support of
GMPLS deployment.
2. Terminology
LSP: Label Switched Path
MPLS-TE LSP: Multi Protocol Label Switching Traffic Engineering LSP
PSC: Packet Switch Capable
LSC: Lambda Switch Capable
Head-end LSR: ingress LSR
Tail-end LSR: egress LSR
LSR: Label Switching Router
3. Problem Statement
GMPLS technology is deployed or will be deployed in various forms to
provide a highly efficient transport for existing MPLS-TE networks,
depending on the deployment choices of each service provider. A GMPLS
K.Kumaki, et al. Expires December 27, 2006 [Page 3]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
network may provide connectivity in terms of LSPs that are used as TE
links by the MPLS-TE network to support MPLS-TE LSPs.
In terms of MPLS-TE/GMPLS signaling, although GMPLS LSPs may be set
up triggered by the signaling of MPLS-TE LSPs, the clear mechanism of
how to interwork has not yet been defined. Feature richness of MPLS-
TE and GMPLS technology allows service providers to use a set of
options on how GMPLS services can be used by MPLS-TE networks. In
this document, the requirement for MPLS-TE/GMPLS interworking is
presented with some operations considerations associated with use of
GMPLS services by MPLS-TE networks.
4. Reference model
The reference model used in this document is shown in Figure 1. As
indicated in [RFC3945], the optical transport network consists of,
for example, GMPLS controlled OXCs and GMPLS-enabled MPLS-TE routers.
Interworking point Interworking point
^ ^
| |
GMPLS LSPs
|MPLS-TE LSPs |------------------------------|MPLS-TE LSPs |
|-----------------|------------------------------|-----------------|
| |------------------------------| |
MPLS-TE network | Optical Transport |MPLS-TE network
| (GMPLS) Network |
+---------+ +--------+ +------+ +------+ +--------+ +---------+
| | | | | | | | | | | |
| MPLS-TE +--+ GMPLS +--+ +--+ +--+ GMPLS +--+ MPLS-TE |
| Service | |Enabled | | OXC1 | | OXC2 | |Enabled | | Service |
| Network +--+ router | | +--+ | | router +--+ Network |
| | | | | | | | | | | |
+---------+ +--------+ +------+ +------+ +--------+ +---------+
Figure 1. Reference model of MPLS-TE/GMPLS interworking
MPLS-TE network connectivity is provided through a GMPLS LSP which is
created between GMPLS routers. This document defines the requirements
for how the MPLS-TE network and the GMPLS network are interworked in
order to effectively operate the entire network and smoothly deploy
the GMPLS network.
5. Detailed Requirements
This section describes detailed requirements for MPLS-TE/GMPLS
interworking in support of GMPLS deployment.
K.Kumaki, et al. Expires December 27, 2006 [Page 4]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
5.1 Use of GMPLS optical network resources in MPLS-TE networks
The solution SHOULD provide the ability to make effective use of
GMPLS optical network resources (e.g. bandwidth, protection &
recovery) by the MPLS-TE service networks.
The GMPLS network MUST be able to support more than one MPLS-TE
network. Most of service providers have different networks for
various services; their GMPLS deployment plans are to have these
service networks use a common GMPLS controlled optical network as a
core network of various services.
5.2 Mapping signaling information between MPLS-TE and GMPLS
The solution SHOULD provide the ability to map signaling information
between MPLS-TE and GMPLS. From an MPLS-TE signaling point of view,
the routers in MPLS-TE domain should be able to signal over GMPLS
optical domain. In this case, an interworking between MPLS-TE and
GMPLS protocol is required.
5.3 Establishment of GMPLS LSPs triggered by end-to-end MPLS-TE LSPs
signaling
The solution SHOULD provide the ability to establish end-to-end MPLS-
TE LSPs over a GMPLS optical network. GMPLS LSPs SHOULD be set up
triggered by the signaling of MPLS-TE LSP.
5.4 Establishment of end-to-end MPLS-TE LSPs having diverse paths over
GMPLS optical network
The solution SHOULD provide the ability to establish end-to-end
MPLS-TE LSPs having diverse paths including diverse GMPLS LSPs
corresponding to the request of the head-end MPLS LSR for protection
of MPLS-TE LSPs. The GMPLS optical network SHOULD assure the
diversity of GMPLS LSPs, even if their ingress nodes in GMPLS optical
network are different.
5.5 Advertisement of TE information via GMPLS optical domain
The solution SHOULD provide the ability to control advertisements of
TE information belonging to MPLS-TE service networks across the GMPLS
optical network.
The TE information within the same MPLS-TE service networks needs to
be exchanged in order that a head end LSR of the MPLS-TE network can
compute an LSP to a tail end LSR that is reached over the GMPLS
optical network.
On the other hand, the TE information belonging to one MPLS-TE
service network MUST NOT be advertised to other MPLS-TE service
K.Kumaki, et al. Expires December 27, 2006 [Page 5]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
networks to preserve confidentiality and security, and in order to
avoid establishing undesirable LSPs.
5.6 Selective advertisement of TE information via a border node
The solution SHOULD provide the ability to distribute TE reachability
information from the GMPLS optical network to MPLS-TE networks
selectively, which are useful for the head-end MPLS routers to
compute MPLS-TE LSPs.
5.7 Interworking of MPLS-TE and GMPLS protection
The solution SHOULD provide the ability to select GMPLS protection
types for the GMPLS LSPs according to protection options defined for
the protected MPLS-TE LSPs.
If MPLS-TE LSPs are protected using MPLS FRR [RFC4090], then when an
FRR protected packet LSP is signaled, we SHOULD be able to select
protected GMPLS LSPs in the GMPLS optical network. In terms of MPLS
protection, the MPLS-TE Path message can include some flags in the
FAST REROUTE object and SESSION_ATTRIBUTE object. In terms of GMPLS
protection, there are both signaling aspects [RFC3471] [RFC3473] and
routing aspects [RFC4202].
5.8 Failure recovery
The solution SHOULD provide failure recovery in the GMPLS optical
domain without impacting MPLS-TE domain and vice versa.
In case that failure in the GMPLS optical domain associates with
MPLS-TE domain, some kind of notification of the failure may be
transmitted to MPLS-TE domain and vice versa.
5.9 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 over
service provider networks.
5.10 Scalability consideration
The solution MUST have a minimum impact on network scalability for
deploying GMPLS technology in the existing MPLS-TE networks.
Scalability of GMPLS deployment in the existing MPLS-TE networks MUST
address the following consideration.
- the number of GMPLS capable nodes (e.g. the number of non-PSC GMPLS
capable nodes)
- the number of MPLS-TE capable nodes
- the number of GMPLS LSPs
K.Kumaki, et al. Expires December 27, 2006 [Page 6]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
- the number of MPLS-TE LSPs
5.11 Performance consideration
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 and so on
- Impact and scalability of the data/forwarding plane due to added
overheads and so on
5.12 Management consideration
Manageability of MPLS-TE/GMPLS interworking MUST addresses the
following consideration.
- need for a MIB module for control plane and monitoring
- need for diagnostic tools
MIB for an interworking between MPLS-TE and GMPLS protocol SHOULD be
implemented.
In case that an interworking between MPLS-TE and GMPLS protocol is
done, a failure between them MUST be detected.
6. Security Considerations
We will write security considerations in next version.
7. IANA Considerations
This requirement document makes no requests for IANA action.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC3945, October 2004.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC3471, January
2003.
K.Kumaki, et al. Expires December 27, 2006 [Page 7]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003.
[RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC4202, October 2005.
9 .Acknowledgments
The author would like to express the thanks to Raymond Zhang, Adrian
Farrel for their helpful and useful comments and feedback.
10.Author's Addresses
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357
Saitama, 356-8502. Japan Email: otani@kddilabs.jp
Shuichi Okamoto
NICT JGN II Tsukuba Reserach Center
1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117
Tokyo, 100-0004, Japan E-mail :okamot-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
11.Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
K.Kumaki, et al. Expires December 27, 2006 [Page 8]
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
K.Kumaki, et al. Expires December 27, 2006 [Page 9]