One document matched: draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt
CCAMP Working Group
Kenji Kumaki
KDDI Corporation Cisco Systems
Zafar Ali
Cisco Systems
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Mallik Tatipamula
Cisco Systems
Internet Draft
Category: Standard Track
Expires: August 2005 February 2005
MPLS/ GMPLS Interworking
draft-kumaki-ccamp-mpls-gmpls-interworking-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.
K. Kumaki, et al. Page 1 2/14/2005
[Page 1]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
Abstract
In order to deploy GMPLS technology in the existing IP/ MPLS
networks, some interworking aspect of GMPLS/ MPLS needs to be
addressed. One of the important aspects of MPLS/ GMPLS interworking
is ability to effectively use GMPLS services in IP/ MPLS networks.
This includes ability to specify GMPLS LSPs in signaling requests
based on the type of the setup desired, as well as considerations for
the operation aspects of using GMPLS LSPs.
In this draft, we highlight some MPLS/ GMPLS interworking
requirements and propose solutions to address them. We also highlight
some operation aspects of the possible solution and provide
applicability statement for the available options.
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 some MPLS/ GMPLS Interworking aspects.
WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK?
This work fits in the context of MPLS/ GMPLS interworking.
WHY IS IT TARGETED AT THIS WG?
This document is targeted at ccamp as it addresses some MPLS/
GMPLS Interworking aspects.
RELATED REFERENCES
Please refer to the reference section.
Table of Contents
1. Introduction...................................................3
K. Kumaki, et al. Page 2 2/14/2005
[Page 2]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
2. Static vs. signaling triggered dynamic FA-LSPs..............3
3. MPLS/ GMPLS LSP Priority Mapping............................4
3.1 OSPF extensions for Link Priority Identification...........5
3.2 ISIS extensions for Link Priority Identification...........6
4. Signaling Protected MPLS LSPs..................................7
5. Applicability...............................................7
5.1 Applicability of the Priority Management Options...........7
5.2 Applicability of the Signaling Triggered Dynamic FA-LSP....8
6. Backward Compatibility Note....................................8
7. Security Considerations........................................8
8. IANA Considerations............................................9
9. Full Copyright Statement.......................................9
10. Intellectual Property.........................................9
11. IPR Disclosure Acknowledgement................................9
12. Reference....................................................10
12.1 Normative Reference......................................10
12.2 Informative Reference....................................10
13. Author's Addresses...........................................10
1. Introduction
Introduction of GMPLS technology in existing IP/ MPLS networks and
migration of IP/ MPLS services to GMPLS core poses some new
requirements that does not exists while using point to point physical
links in the core network. Specifically, GMPLS technology is equipped
with features like priority management and protection and
restoration. These features have some implications on how IP/ MPLS
networks can utilize forwarding and/ or routing adjacencies
established on top of GMPLS networks. In this draft, we highlight
these implications/ requirements and propose solutions to address
them. In this fashion this draft complements [GMPLS-migration] draft,
which formalizes the MPLS/ GMPLS interworking problem. Using the
terminology used in [GMPLS-migration], this draft addresses only
MPLS-GMPLS-MPLS case.
Feature richness of MPLS and GMPLS technology allows service
providers to use a set of options on how GMPLS services can be used
by IP/ MPLS networks. However, there are some operational
considerations and pros and cons associated with the individual
options. This draft also highlights some operations considerations
associated with use of GMPLS services by IP/ MPLS networks.
2. Static vs. signaling triggered dynamic FA-LSPs
From signaling prospective, clearly there are two alternatives in
which setup for GMPLS tunnel can be triggered: Static (pre-
K. Kumaki, et al. Page 3 2/14/2005
[Page 3]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
configured) and Dynamic (on-demand based on signaling setup request
for MPLS LSP).
Decision to establish new Static GMPLS LSPs are made either by the
operator or automatically (e.g., using features like TE auto-mesh).
In either case, Static FA-LSP are established and advertised prior to
setup of MPLS LSPs using them in the ERO. In case of static FA-LSP,
if MPLS LSP setup request (MPLS RSVP Path message) cannot be
satisfied by existing Static FA-LSPs, it is rejected.
Dynamic FA-LSP is triggered by RSVP Path message for setting up an
MPLS LSP. Please note that dynamic FA-LSPs can be virtual FAs from
routing prospective. In either case, LSP creation from signaling
prospective is triggered by the MPLS RSVP Path message received at a
MPLS/ GMPLS border router.
In the case of Static or Virtual FA-LSPs, the FA may be specified in
an ERO encoded as strict ERO. In the case where FA-LSPs are dynamic
and are not advertised as virtual links in the MPLS TE topology, MPLS
signaling request (MPLS RSVP Path message) contains a loose ERO, and
GMPLS LSP selection is a local decision at the border router. In the
case of Static or Virtual FA-LSPs, a signaling request may also be
encoded as loose ERO.
When the border router receives the signaling setup request and
determines that in order for it to extend the loose ERO content, it
needs to create GMPLS FA-LSP. Consequently, it signals a GMPLS LSP
respecting MPLS/ GMPLS signaling interworking aspects discussed in
sections 4.1 and 4.2. Once the GMPLS FA-LSP is fully established, the
ERO contents for the MPLS signaling setup request are extended to use
the GMPLS LSP and signaling setup for the FA-LSP are carried in-band
of the GMPLS LSP. The GMPLS LSP can then also be advertised as an FA-
LSP in MPLS TE topology or an IGP adjacency can be brought up on the
GMPLS LSP.
3. MPLS/ GMPLS LSP Priority Mapping
Both MPLS and GMPLS LSPs are signaled for specific setup and hold
priority, based on the importance of traffic carried over them. For
proper operation of the network, it is desirable to create/ use GMPLS
LSPs of specified setup and hold priority, based on the setup and
hold priority of the MPLS LSPs using them.
In the following, we discuss several approaches possible for mapping
setup and hold priority of MPLS LSPs to GMPLS FA-LSPs.
K. Kumaki, et al. Page 4 2/14/2005
[Page 4]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
1) Exact Match: In this case setup and hold priority of the GMPLS FA-
LSP is same as setup and hold priority of MPLS LSP using it. In other
words, GMPLS LSP Priority set = MPLS LSP Priority set.
2) Better Priority: In this case GMPLS FA-LSP can be of setup and
hold priority equal better than the MPLS LSP using it. In other
words, GMPLS LSP Priority set <= MPLS LSP Priority set.
3) Dynamic Priority for GMPLS LSP: In this case priority of GMPLS LSP
is dynamically changed based on priority of the MPLS LSPs using it.
In other words, GMPLS LSP Priority set = min (MPLS LSP Priority set).
4) Any to Any Mapping Matrix: Based on some policies, it is possible
to have any-to-any mapping for MPLS/ GMPLS priority mapping at the
MPLS/ GMPLS border router.
5) No Priority Management in GMPLS core: In this simple minded
approach all GMPLS LSPs can be establish with setup and hold priority
of "0", i.e., the GMPLS LSPs are already set as better match. In this
case, priority management is handled purely at MPLS layer, with GMPLS
network providing L1 connectivity without priority management.
In the case of a strict ERO, a remote MPLS node can only select an
FA-LSP during its SPF calculation if it knows the setup and hold
priority of the GMPLS FA-LSP. In the following, we propose some
routing extension that can be used by the border routers to advertise
setup and hold priorities of the FA-LSPs or ability/ wiliness to
dynamically change setup and hold priority of the FA-LSP.
3.1 OSPF extensions for Link Priority Identification
This section we define the enhancements to the TE properties of GMPLS
TE links that can be announced in OSPF TE LSAs [OSPF-TE] to carry
link state information regarding setup and hold priority of the FA-
LSP. Specifically, we add the following sub-TLV to the Link TLV:
Sub-TLV Type Length Name
TBD 4 Link Priority Identifiers
Link Priority Identifiers
A Link Priority Identifiers is a sub-TLV of the Link TLV. This
identifier carries the setup and hold priority for the FA-LSP links.
The type of this sub-TLV is TBD, and length is four octets. The
following Figure illustrates encoding of the link priority
Identifiers sub-TLV.
K. Kumaki, et al. Page 5 2/14/2005
[Page 5]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this sub-TLV contains one octet of setup priority
of the FA-LSP, followed by one octet of hold priority of the FA-LSP.
Based on a local policy, advertising LSR may be able to dynamically
adjust priority of the FA-LSP, in which case it sets ôDö bit in the
following octet (as shown above). The remaining bits SHOULD be set to
zero by the sender, and SHOULD be ignored by the receiver.
This setup and hold priority parameters are copied from the values
carried in the RSVP Session Attribute Object when the FA-LSP is
signaled. Please refer to [RFC3209] for details on the setup and hold
priorities parameters and how they are encoded. Inclusion of this
sub-TLV is not needed for the physical links, however one may carry
it with setup and hold priorities set to 0.
3.2 ISIS extensions for Link Priority Identification
This section we define the enhancements to the extended IS
reachability TLV (see [ISIS-TE]). Specifically, we add the following
sub-TLVs:
Sub-TLV Type Length Name
TBD 4 Link Priority Identifiers
Link Priority Identifiers
A Link Priority Identifiers is a sub-TLV of the extended IS
reachability TLV. This identifier carries the setup and hold priority
for the FA-LSP links.
The type of this sub-TLV is TBD, and length is four octets. The
following Figure illustrates encoding of the Link Priority
Identifiers sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K. Kumaki, et al. Page 6 2/14/2005
[Page 6]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
The value field of this sub-TLV contains one octet of setup priority
of the FA-LSP, followed by one octet of hold priority of the FA-LSP.
Based on a local policy, advertising LSR may be able to dynamically
adjust priority of the FA-LSP, in which case it sets ôDö bit in the
following octet (as shown above). The remaining bits SHOULD be set to
zero by the sender, and SHOULD be ignored by the receiver.
The setup and hold priority parameters are copied from the values
carried in the RSVP Session Attribute Object when the FA-LSP is
signaled. Please refer to [RFC3209] for details on the setup and hold
priorities parameters and how they are encoded. Inclusion of this
sub-TLV is not needed for the physical links, however one may carry
it with setup and hold priorities set to 0.
4. Signaling Protected MPLS LSPs
When MPLS LSPs are protected using MPLS-FRR mechanism [TE-FRR] and it
may be desired to signal MPLS LSP such that it uses protected GMPLS
tunnel FA-LSPs. In this section we discuss MPLS/ GMPLS interworking
aspect for protected MPLS LSPs.
In the case of loose ERO, where selection of GMPLS FA-LSP is a left
for the border nodes and ôLocal protection desiredö flag of the
SESSION_ATTRIBUTE object is set, the border router SHOULD try to map
the signaling setup request to a GMPLS LSP which is protected within
GMPLS domain. However, in the case of strict ERO, the selection of
GMPLS FA-LSP is based on the contents of the ERO and ôLocal
protection desiredö flag is ignored.
5. Applicability
In this section we discuss some operational considerations and pros
and cons associated with the individual options listed in Section 3.
5.1 Applicability of the Priority Management Options
In section 4.1, various options from exact match to no priority
management in GMPLS network are discussed. This section provides an
applicability of these options.
The benefit of Priority Management in GMPLS Core comes at the cost of
bandwidth fragmentation. E.g., in simplest approach of exact match,
we need at least as many GMPLS LSPs, as there are priority
combination in the network, while the other extreme of no priority
management in GMPLS network does allow full aggregation of MPLS
traffic on GMPLS FAs, i.e. avoids bandwidth fragmentation. If IGP
adjacency is to be established over the GMPLS LSPs, having more GMPLS
K. Kumaki, et al. Page 7 2/14/2005
[Page 7]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
LSP leads to more links in the IGP/ IP topology. The same is true of
MPLS TE topology with the exception that FA-LSPs can be bundled to
avoid flooding of multiple TE links.
With priority management within GMPLS network, there is a danger of
creating oscillations in the IP/MPLS network using GMPLS. This is
because when a new FA-LSP is established based on a local routing
decision made at the border router; we can have undesirable
preemption affecting MPLS LSPs carried over the GMPLS LSP that is
being preempted. This can have cascading affect leading to
oscillations on the operation of MPLS traffic.
5.2 Applicability of the Signaling Triggered Dynamic FA-LSP
In this section, we discussed applicability of static vs. dynamic FA-
LSPs. It is important to realize that we can have FA-LSPs that are
created dynamically based on triggers like configuration, link
utilization level, etc. However, in the context of this document,
such FA-LSPs are considered as static FAs. In this document, the term
dynamic FA-LSPs are used for FA-LSPs that are triggered by RSVP Path
message for MPLS LSP.
Signaling triggered dynamic FA-LSPs are addressing a problem space
where traffic pattern cannot be predicted or objective is to optimize
operations of the network based on actually signaled request rather
than predicted use of the network resource (i.e., off-line traffic
engineering).
The problem with the use of signaling triggered dynamic FA-LSPs is
that we loose ability to better aggregate the traffic request at the
border routers. This leads to potential cases of bandwidth
fragmentation inside GMPLS core, which has disadvantages discussed in
Section 4.2. Furthermore, signaling triggered dynamic FA-LSPs coupled
with preemption can lead to oscillations in the operation of the
network. This is because when a new FA-LSP is dynamically established
based on a local routing decision made at the border router; we can
have undesirable preemption affecting MPLS LSPs carried over the
GMPLS LSP that is being preempted. This can have cascading affect
leading to oscillations on the operation of MPLS traffic.
6. Backward Compatibility Note
The procedure presented in this document is backward compatible with
[RFC3630], [RFC3784], [RFC3209] and [RFC3473].
7. Security Considerations
K. Kumaki, et al. Page 8 2/14/2005
[Page 8]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
This document does not introduce new security issues.
8. IANA Considerations
Sub-TLV type for Link Priority Identifiers is to be assigned.
9. 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
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.
10. 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.
11. IPR Disclosure Acknowledgement
K. Kumaki, et al. Page 9 2/14/2005
[Page 9]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
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.
12. Reference
12.1 Normative Reference
[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.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
[GMPLS-mig] IP/MPLS - GMPLS interworking in support of IP/MPLS to
GMPLS migration, draft-oki-ccamp-gmpls-ip-interworking-04.txt, D.
Brungard, et al.
12.2 Informative Reference
[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.
[TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE",
draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, August 2004 (Work in
Progress).
13. Author's Addresses
Kenji Kumaki
KDDI Corporation
K. Kumaki, et al. Page 10 2/14/2005
[Page 10]
draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
E-mail : ke-kumaki@kddi.com
Zafar Ali
Cisco systems, Inc.,
2000 Innovation Drive Phone: 613 254 3498
Kanata, Ontario Email: zali@cisco.com
Canada K2K 3E8
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
Mallik Tatipamula
Cisco systems, Inc.,
170 W. Tasman Drive
San Jose, CA 95134 Phone: 408 525 4568
USA. Email: mallikt@cisco.com
K. Kumaki, et al. Page 11 2/14/2005
[Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 03:25:28 |