CCAMP Working Group Zafar Ali
George Swallow
Mallik Tatipamula
Cisco Systems
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Kenji Kumaki
KDDI Corporation
Internet Draft
Category: BCP
Expires: August 2005 February 2005
GMPLS Deployment in Existing IP/MPLS networks
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 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.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Z. Ali, et al. Page 1 2/14/2005
[Page 1]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
Abstract
One of the biggest challenges faced by GMPLS technology is ôhow it
can be deployedö in a manner least impacting to existing IP/ MPLS
networks. GMPLS architecture document lists [RFC3945] three different
scenarios in which GMPLS technology can be deployed: overlay,
augmented and integrated. Reference [GMPLS-mig] addresses the problem
of migration from MPLS to GMPLS networks using the integrated model.
This draft addresses the same problem space for augmented model and
illustrates the applicability of augmented model in deploying GMPLS
technology in existing IP/ MPLS networks.
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
[RFC2119].
Routing Area ID Summary
(This section to be removed before publication.)
SUMMARY
This document addresses GMPLS deployment aspects.
WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK?
This work fits in the context of GMPLS deployment.
WHY IS IT TARGETED AT THIS WG?
This document is targeted at ccamp as it addresses GMPLS
deployment aspects.
RELATED REFERENCES
Please refer to the reference section.
Table of Contents
1. Introduction...................................................3
2. Augmented Model................................................4
2.1 Routing in Augmented Model.................................4
2.2 Failure Recovery in Augmented Model........................4
Z. Ali, et al. Page 2 2/14/2005
[Page 2]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
2.3 Management in Augmented model..............................5
3. GMPLS Deployment Considerations................................5
3.1 Applicability of virtual FA-LSP............................6
3.2 Applicability of FA Utilization............................6
4. Backward Compatibility Note....................................6
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. Full Copyright Statement.......................................6
8. Intellectual Property..........................................7
9. IPR Disclosure Acknowledgement.................................7
10. Reference.....................................................7
10.1 Normative Reference.......................................7
10.2 Informative Reference.....................................8
11. Author's Addresses............................................8
1. Introduction
One of the biggest challenges in todayÆs network is ôhow to deploy
GMPLS technologyö in a manner least impact on the existing IP/ MPLS
networks. It is neither feasible nor desired to upgrade all existing
nodes to GMPLS technology. In fact, it is required to minimize the
impact of migration to GMPLS on the existing IP/ MPLS network. It is
also desired to respect the administrative boundaries between IP/MPLS
and Optical domains.
There are several architectural alternatives including overlay,
integrated and augmented models proposed in GMPLS architecture
document [RFC3945]. The key difference among these models is how much
and what kind of network information can be shared between packet and
Optical domains. Peer model is suitable, where optical transport and
Internet/Intranet Service networks are operated by a single entity.
Currently, many service providers have traditionally built their
networks, where Optical transport and IP/MPLS service networks belong
to different operation/management/ownership. Most important thing is
that service providers wants to operate and manage their networks
independently, and deploy them without changing existing IP/MPLS
network topologies, protocols and scalability. Overlay model is
suitable for such scenario, however does not offer the benefits of
peer model approach for efficient resource utilization, optimal
routing and protection and restoration between IP/MPLS and Optical
networks. Augmented model is suitable in this scenario, where Optical
transport and IP/MPLS service networks administrated by different
entities and would like to maintain a separation between IP/MPLS and
Optical layers, at the same time, get the benefits of integrated
model approach.
Z. Ali, et al. Page 3 2/14/2005
[Page 3]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
Reference [GMPLS-mig] addresses the problem of migration from MPLS to
GMPLS networks using the integrated model. This draft addresses the
GMPLS deployment considerations using augmented model and illustrates
how it can be used in existing IP, MPLS and non-IP/MPLS networks. In
this regard, there are three different considerations taken into
account while comparing these approaches. They are: Deployment
considerations, routing aspects, and failure recovery considerations.
2. Augmented Model
Augmented Model is introduced in GMPLS Architecture document
[RFC3945]. It is a hybrid model between the full peer and overlay
models. Border nodes at the edge of IP/MPLS domain and optical domain
receive routing information from the optical devices (in optical
domain) and nodes (in IP/MPLS domain). Based on this information,
border node keeps the optical and IP/MPLS routing domain topology
information in separate topology database. No routing information
from the router region is carried into the optical region and vice
versa.
| Optical Transport |
| Network |
+--------+ +--------+ +-------+ +-------+ +--------+ +---------+
| | | | | | | | | | | |
| IP/MPLS+--+ Border +--+--+ OXC1 +--+ OXC2 +-+--+ Border +---+ IP/MPLS |
| Service| | Node | | | | | | Node | | Service |
| Network| | | | | | | | | | Network |
+-----+--+ +---+----+ +-----+-+ +---+---+ +--------+ +---------+
2.1 Routing in Augmented Model
Augmented model maintains a separation between optical and routing
topologies; unlike integrated model approach, where topology
information is shared between IP/MPLS and Optical domains.
Nonetheless, as the border node has full knowledge of the optical
network, it can compute routes for GMPLS LSPs within the optical
domain. This allows augmented model to be more efficient in resource
utilization than overlay model, such that router and optical domain
resource can be optimized. At the same time, it can yield more
efficient use of resources, similar to the full peer model.
2.2 Failure Recovery in Augmented Model
Both integrated model and augmented model offer a tighter
coordination between IP/MPLS and optical layers, which helps to
resolve uncorrelated failures. This is unlike overlay model, which
offers no coordination between optical and IP/MPLS layers;
Z. Ali, et al. Page 4 2/14/2005
[Page 4]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
consequently a single failure in one layer may trigger uncorrelated
failures in the other domain, which may complicate the fault
handling.
Another important aspect in augmented model is failure transparency,
i.e., a failure in optical network does not affect operations at
router network and vice versa. Specifically, failure in the optical
domain does not affect services in routing (IP/MPLS) domain, and
failure can be restored/ repaired in optical domain without impacting
IP/MPLS domain and vice versa. Where as in peer model, since optical
and IP/MPLS domains share the same topology and routing information,
failure in optical domain is visible to IP/MPLS domain and vice
versa.
2.3 Management in Augmented model
Currently, many service providers have traditionally built their
networks, where Optical transport and IP/MPLS service networks belong
to different operation/management/ownership. In augmented model, each
network administrator can operate and manage his network
independently because this model maintains a complete separation
between these networks.
3. GMPLS Deployment Considerations
In the integrated model, since all the devices in optical and routing
domains share the same topology and routing information with same IGP
instance, it requires all the devices within peer model to be
MPLS/GMPLS aware. Reference [GMPLS-mig] discusses various aspects of
migration from MPLS to GMPLS technology using integrated model.
In augmented model, as shown in figure 1, devices within optical and
its routing domains have no visibility into others topology and/or
routing information, except the border nodes. This will help
augmented model to accommodate both MPLS based or non-MPLS based
service networks connected to border nodes, as long as Border node in
augmented model can support GMPLS control plane.
One of the main advantages of the augmented model in the context of
GMPLS deployability is that it does not require existing IP/ MPLS
networks to be GMPLS aware. Only border nodes need to be upgraded
with the GMPLS functionality. In this fashion, augmented model
renders itself for incremental deployment of the optical regions,
without requiring reconfiguration of existing areas/ASes, changing
operation of IGP and EGP or software upgrade of the existing IP/MPLS
service networks.
Z. Ali, et al. Page 5 2/14/2005
[Page 5]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
3.1 Applicability of virtual FA-LSP
Virtual FA-LSPs discussed in [GMPLS-mig] are equally applicable to
the integrated and augmented models. Specifically, in augmented
model, the border node can advertise virtual GMPLS FA-LSPs into
IP/MPLS network and can establish the LSP statically or dynamically
on as needed basis.
3.2 Applicability of FA Utilization
There are several possible schemes for determining how many FAs to
provision, when to enable the FAs, and whether to choose FAs of
virtual FAs as discussed in [GMPLS-mig] for integrated model. These
aspects of FA Utilization are equally applicable to augmented model,
with intelligence of FA Utilization implemented at the border node.
4.3 Bundling FA-LSP
In augmented model, it is also possible to bundle GMPLS FA-LSPs at
the border nodes. Since IP/ MPLS network will only see a bundled link
with TE or IGP attributes, operations on the bundled link, e.g.,
adding a new component link, failure of a component link, etc., are
completely transparent to the rest of the network.
4. Backward Compatibility Note
The procedure presented in this document is backward compatible with
[RFC3630], [RFC3784], [RFC3209] and [RFC3473].
5. Security Considerations
This document does not introduce new security issues.
6. IANA Considerations
No.
7. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
Z. Ali, et al. Page 6 2/14/2005
[Page 6]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
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.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
10. Reference
10.1 Normative Reference
[RFC3945] ôGeneralized Multi-Protocol Label Switching (GMPLS)
Architectureö, RFC 3945, E. Mannie, October 2004.
[GMPLS-mig] ôIP/MPLS - GMPLS interworking in support of IP/MPLS to
GMPLS migrationö, draft-oki-ccamp-gmpls-ip-interworking-04.txt
work in progress, October 2004 .
Z. Ali, et al. Page 7 2/14/2005
[Page 7]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
10.2 Informative Reference
[GMPLS-overlay] Generalize Multiprotocol Label Switching(GMPLS)User-
Network Interface (UNI): Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Support for the Overlay Modelö, draft-ietf-
ccamp-gmpls-overlay-05.txt, work in progress, October 2004.
[RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification", RFC 2205, Braden, et al, September
1997.
[RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, RFC 3471, L. Berger, et al,
January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
TE) Extensions", RFC 3473, L. Berger, et al, January 2003.
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
RFC 3209, December 2001.
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
June 2004.
11. Author's Addresses
Zafar Ali
Cisco systems, Inc.,
2000 Innovation Drive Phone: 613 254 3498
Kanata, Ontario Email: zali@cisco.com
Canada K2K 3E8
George Swallow
Cisco Systems, Inc.
1414 Massachusetts Ave,
Boxborough, MA 01719
Phone: +1 978 936 1398
Email: swallow@cisco.com
Z. Ali, et al. Page 8 2/14/2005
[Page 8]
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005
Mallik Tatipamula
Cisco systems, Inc.,
170 W. Tasman Drive
San Jose, CA 95134 Phone: 408 525 4568
USA. Email: mallikt@cisco.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
E-mail : 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
Z. Ali, et al. Page 9 2/14/2005
[Page 9]