draft-ietf-ccamp-lsp-hierarchy-bis-06.txt   draft-ietf-ccamp-lsp-hierarchy-bis-07.txt 
Network Working Group K. Shiomoto (Ed.) Network Working Group K. Shiomoto (Ed.)
Internet Draft NTT Internet Draft NTT
Updates: 3477, 4206 A. Farrel (Ed.) Updates: 3477, 4206 A. Farrel (Ed.)
Proposed Category: Proposed Standard Old Dog Consulting Proposed Category: Proposed Standard Old Dog Consulting
Created: December 9, 2008 Created: October 19, 2009
Expires: June 9, 2009 Expires: April 19, 2010
Procedures for Dynamically Signaled Procedures for Dynamically Signaled
Hierarchical Label Switched Paths Hierarchical Label Switched Paths
draft-ietf-ccamp-lsp-hierarchy-bis-06.txt draft-ietf-ccamp-lsp-hierarchy-bis-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
for carrying traffic in those networks or in other (client) networks. to carry traffic in those networks or in other (client) networks.
Protocol extensions already exist to facilitate the establishment of Protocol mechanisms already exist to facilitate the establishment of
an LSP as a numbered traffic engineering (TE) link within the same such LSPs and to bundle TE links to reduce the load on routing
instance of the routing as is used to advertise the links that it protocols. This document defines extensions to those mechanisms to
traverses creating a Forwarding Adjacency (FA). This document extends support identifying the use to which such LSPs are to be put and to
those mechanisms to support unnumbered FAs. enable the TE link endpoints to be assigned addresses or unnumbered
identifiers during the signaling process.
This document also defines how to indicate that an LSP should be The mechanisms defined in this document deprecates the technique
advertised as a link in another instance of the routing protocol (for for the signaling of LSPs that are to be used as numbered TE links
instance in a client network) and which instance to use. Furthermore, described in RFC 4206.
mechanisms are defined to indicate when an LSP is to be used as a
component link of a TE link bundle and to identify the bundle.
Conventions used in this document Conventions used in this document
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]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction and Problem Statement ............................. 3 1. Introduction and Problem Statement ............................. 3
1.1. Background ................................................... 4 1.1. Background ................................................... 4
1.1.1. Hierarchical LSPs .......................................... 4 1.1.1. Hierarchical LSPs .......................................... 4
1.1.2. LSP Stitching Segments ..................................... 4 1.1.2. LSP Stitching Segments ..................................... 4
1.1.3. Private Links .............................................. 4 1.1.3. Private Links .............................................. 5
1.1.4. Routing Adjacencies ........................................ 4 1.1.4. Routing Adjacencies ........................................ 5
1.1.5. Forwarding Adjacencies ..................................... 5 1.1.5. Forwarding Adjacencies ..................................... 5
1.1.6. Client/Server Networks ..................................... 5 1.1.6. Client/Server Networks ..................................... 5
1.1.7. Link Bundles ............................................... 5 1.1.7. Link Bundles ............................................... 6
1.2. Desired Function ............................................. 6 1.2. Desired Function ............................................. 6
1.3. Existing Mechanisms .......................................... 6 1.3. Existing Mechanisms .......................................... 6
1.3.1. LSP Setup .................................................. 6 1.3.1. LSP Setup .................................................. 6
1.3.2. Routing Adjacency Establishment and Link State Advertisement 6 1.3.2. Routing Adjacency Establishment and Link State Advertisement 6
1.3.3. TE Link Advertisement ...................................... 6 1.3.3. TE Link Advertisement ...................................... 7
1.3.4. Configuration and Management Techniques .................... 7 1.3.4. Configuration and Management Techniques .................... 7
1.3.5. Signaled Unnumbered FAs .................................... 7 1.3.5. Signaled Unnumbered FAs .................................... 7
1.3.6. Establishing Numbered FAs Through Signaling and Routing .... 8 1.3.6. Establishing Numbered FAs Through Signaling and Routing .... 8
1.4. Overview of Required Extensions .............................. 9 1.4. Overview of Required Extensions .............................. 9
1.4.1. Efficient Signaling of Numbered FAs ........................ 9 1.4.1. Efficient Signaling of Numbered FAs ........................ 9
1.4.2. LSPs for Use as Private Links .............................. 9 1.4.2. LSPs for Use as Private Links .............................. 9
1.4.3. Signaling an LSP For use in Another Network ................ 9 1.4.3. Signaling an LSP For use in Another Network ............... 10
1.4.4. Signaling an LSP for Use in a Link Bundle .................. 9 1.4.4. Signaling an LSP for Use in a Link Bundle ................. 10
1.4.5. Support for IPv4 and IPv6 ................................. 10 1.4.5. Support for IPv4 and IPv6 ................................. 10
1.4.6. Backward Compatibility .................................... 10 1.4.6. Backward Compatibility .................................... 10
2. Overview of Solution .......................................... 10 2. Overview of Solution .......................................... 10
2.1. Common Approach for Numbered and Unnumbered Links ........... 10 2.1. Common Approach for Numbered and Unnumbered Links ........... 10
2.2. LSP Usage Indication ........................................ 10 2.2. LSP Usage Indication ........................................ 11
2.3. IGP Instance Identification ................................. 10 2.3. IGP Instance Identification ................................. 11
2.4. Link Bundle Identification .................................. 11 2.4. Link Bundle Identification .................................. 11
2.5. Backward Compatibility ...................................... 11 2.5. Backward Compatibility ...................................... 11
3. Mechanisms and Protocol Extensions ............................ 11 3. Mechanisms and Protocol Extensions ............................ 11
3.1. LSP_TUNNEL_INTERFACE_ID Object .............................. 11 3.1. LSP_TUNNEL_INTERFACE_ID Object .............................. 12
3.1.1. Existing Definition and Usage ............................. 11 3.1.1. Existing Definition and Usage ............................. 12
3.1.2. Unnumbered Links with Action Identification ............... 12 3.1.2. Unnumbered Links with Action Identification ............... 12
3.1.3. IPv4 Numbered Links with Action Identification ............ 14 3.1.3. IPv4 Numbered Links with Action Identification ............ 15
3.1.4. IPv6 Numbered Links with Action Identification ............ 15 3.1.4. IPv6 Numbered Links with Action Identification ............ 15
3.2. Target IGP Identification TLV ............................... 16 3.2. Target IGP Identification TLV ............................... 16
3.3. Component Link Identification TLV ........................... 17 3.3. Component Link Identification TLV ........................... 17
3.3.1. Unnumbered Component Link Identification .................. 18 3.3.1. Unnumbered Component Link Identification .................. 18
3.3.2. IPv4 Numbered Component Link Identification ............... 18 3.3.2. IPv4 Numbered Component Link Identification ............... 18
3.3.3. IPv6 Numbered Component Link Identification ............... 18 3.3.3. IPv6 Numbered Component Link Identification ............... 19
3.4. Link State Advertisement .................................... 19 3.4. Link State Advertisement .................................... 19
3.5. Message Formats ............................................. 20 3.5. Message Formats ............................................. 20
3.6. Error Cases and Non-Acceptance .............................. 20 3.6. Error Cases and Non-Acceptance .............................. 20
3.7. Backward Compatibility ...................................... 21 3.7. Backward Compatibility ...................................... 22
4. Security Considerations ....................................... 22 4. Security Considerations ....................................... 23
5. IANA Considerations ........................................... 23 5. IANA Considerations ........................................... 23
5.1. New Class Types ............................................. 23 5.1. New Class Types ............................................. 23
5.2. Hierarchy Actions ........................................... 23 5.2. Hierarchy Actions ........................................... 23
5.3. New Error Codes and Error Values ............................ 24 5.3. New Error Codes and Error Values ............................ 24
6. Acknowledgements .............................................. 24 6. Acknowledgements .............................................. 25
7. References .................................................... 24 7. References .................................................... 25
7.1. Normative References ........................................ 24 7.1. Normative References ........................................ 25
7.2. Informative References ...................................... 25 7.2. Informative References ...................................... 25
8. Editors' Addresses ............................................ 27 8. Editors' Addresses ............................................ 27
9. Authors' Addresses ............................................ 27 9. Authors' Addresses ............................................ 27
1. Introduction and Problem Statement 1. Introduction and Problem Statement
[RFC4206] defines how to set up Label Switched Paths (LSPs) in Traffic Engineering (TE) links in a Multiprotocol Label Switching
Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from
(TE) networks to be used as hierarchical Label Switched Paths Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as
(H-LSPs). hierarchical LSPs (H-LSPs).
[RFC4201] describes how to collect together TE links between the same The LSPs established in one network may be used as TE links in
pair of nodes and advertise them as a single TE link called a link another network, and this is particularly useful when a server layer
bundle. network (for example, an optical network) provides LSPs for use as TE
links in a client network (for example, a packet network). This
enables the construction of a multilayer networks (MLN) [RFC5212].
[RFC5212] presents a framework and requirements for multilayer When the number of TE links (created from LSPs or otherwise) between
networks (MLNs). This includes the establishment of an LSP in a a pair of nodes grows large, it is inefficient to advertise them
server network that is used as a link in a client network. individually. This may cause scaling issues in configuration and in
the routing protocols used to carry the advertisements. The solution
(described in [RFC4201]) is to collect the TE links together and to
advertise them as a single TE link called a link bundle.
As set out later in this document, issues have been identified during These various mechanisms have proved to be very powerful in building
deployment with how LSPs are established and made available for use dynamically provisioned networks, but, as set out later in this
as H-LSPs or as components of a link bundle and advertised document, several issues have been identified during deployment with
how LSPs are established and made available for use as H-LSPs or as
components of a link bundle, and with how these links are advertised
appropriately in an interior gateway protocol (IGP). These issues appropriately in an interior gateway protocol (IGP). These issues
relate to coordinating between the LSP's end points the use to which relate to coordinating between the LSP's end points the use to which
the LSP is put. the LSP is put, and the allocation of the identifiers of the end
points.
This document gives some basic background, describes the This document provides solutions to the issues by defining mechanisms
requirements, sets out the mechanisms that already exist, and so that the ends of signaled LSPs can exchange information about:
enumerates the protocols extensions and mechanisms that are needed.
The document goes on to present the necessary additions to the GMPLS - Whether the LSP is an ordinary LSP or an H-LSP.
protocols. - In which IGP instances the LSP should be advertised as a link.
- How the client networks should make use of the new links.
- Whether the link should form part of a bundle (and if so, which).
- How the link end points should be identified when advertised.
This document deprecates one of the mechanisms defined in [RFC4206]
for the signaling of LSPs that are to be used as numbered TE links
(see Sections 1.3.6 and 1.4.6 for more details), and provides
extensions to the other mechanisms defined in [RFC4206] so that the
use to which the new LSP is to be put may be indicated during
signaling. It also extends the mechanisms defined in [RFC3477] for
signaling unnumbered TE links.
1.1. Background 1.1. Background
1.1.1. Hierarchical LSPs 1.1.1. Hierarchical LSPs
[RFC3031] describes how Multiprotocol Label Switching (MPLS) labels [RFC3031] describes how Multiprotocol Label Switching (MPLS) labels
may be stacked so that LSPs may be nested with one LSP running may be stacked so that LSPs may be nested with one LSP running
through another. This concept of H-LSPs is formalized in [RFC4206] through another. This concept of H-LSPs is formalized in [RFC4206]
with a set of protocol mechanisms for the establishment of an H-LSP with a set of protocol mechanisms for the establishment of an H-LSP
that can carry one or more other LSPs. that can carry one or more other LSPs.
skipping to change at page 7, line 8 skipping to change at page 7, line 24
TE link advertisement can be performed by the same instance of the TE link advertisement can be performed by the same instance of the
IGP as is used for normal link state advertisement, or can use a IGP as is used for normal link state advertisement, or can use a
separate instance. Furthermore, the ends of a TE link advertised in separate instance. Furthermore, the ends of a TE link advertised in
an IGP do not need to form a routing adjacency. This is particularly an IGP do not need to form a routing adjacency. This is particularly
the case with FAs as described in Section 1.1.5. the case with FAs as described in Section 1.1.5.
1.3.4. Configuration and Management Techniques 1.3.4. Configuration and Management Techniques
LSPs are usually created as the result of a management action. This LSPs are usually created as the result of a management action. This
is true even when a control plane is used ? the management action is is true even when a control plane is used: the management action is a
a request to the control plane to signal the LSP. request to the control plane to signal the LSP.
If the LSP is to be used as an H-LSP or S-LSP, management commands If the LSP is to be used as an H-LSP or S-LSP, management commands
can be used to install the LSP as a link. The link must be defined, can be used to install the LSP as a link. The link must be defined,
interface identifiers allocated, and the end points configured to interface identifiers allocated, and the end points configured to
know about (and advertise, if necessary) the new link. know about (and advertise, if necessary) the new link.
If the LSP is to be used as part of a link bundle, the operator must If the LSP is to be used as part of a link bundle, the operator must
decide which bundle it forms part of and ensure that that information decide which bundle it forms part of and ensure that information is
is configured at the ingress and egress, along with the necessary configured at the ingress and egress, along with the necessary
interface identifiers. interface identifiers.
These mechanisms are perfectly functional and quite common in MLNs, These mechanisms are perfectly functional and quite common in MLNs,
but require configuration coordination and additional management. but require configuration coordination and additional management.
They are open to user error and misconfiguration that might result in They are open to user error and misconfiguration that might result in
the LSP not being used (a waste of resources) or the LSP being made the LSP not being used (a waste of resources) or the LSP being made
available in the wrong way with some impact on traffic engineering. available in the wrong way with some impact on traffic engineering.
1.3.5. Signaled Unnumbered FAs 1.3.5. Signaled Unnumbered FAs
skipping to change at page 8, line 52 skipping to change at page 9, line 21
- Checks the advertising router ID from the advertisement against - Checks the advertising router ID from the advertisement against
the ingress address of each LSPs for which it is the egress the ingress address of each LSPs for which it is the egress
- Deduce the LSP that has been advertised as a TE link and issue - Deduce the LSP that has been advertised as a TE link and issue
the corresponding advertisement for the reverse direction. the corresponding advertisement for the reverse direction.
It is possible that some reduction in processing can be achieved by It is possible that some reduction in processing can be achieved by
mapping based on the /31 pairing, but nevertheless, there is a fair mapping based on the /31 pairing, but nevertheless, there is a fair
amount of processing required, and this does not scale well in large amount of processing required, and this does not scale well in large
networks. networks.
No explanation is provided in [RFC4206] of how to create numbered
IPv6 FAs.
Note that this document deprecates this procedure as explained in Note that this document deprecates this procedure as explained in
Section 1.4.6. Section 1.4.6.
No explanation is provided in [RFC4206] of how to create numbered
IPv6 FAs.
1.4. Overview of Required Extensions 1.4. Overview of Required Extensions
This section provides a brief outline of the required protocol This section provides a brief outline of the required protocol
extensions. extensions.
1.4.1. Efficient Signaling of Numbered FAs 1.4.1. Efficient Signaling of Numbered FAs
The mechanism described in Section 1.3.6. is inefficient. The egress The mechanism described in Section 1.3.6. is inefficient. The egress
must wait until it receives an advertisement from the ingress before must wait until it receives an advertisement from the ingress before
it knows that the LSP is to be installed as a TE link and advertised it knows that the LSP is to be installed as a TE link and advertised
skipping to change at page 24, line 44 skipping to change at page 25, line 7
11 = Link address type or family not supported [This.doc] 11 = Link address type or family not supported [This.doc]
12 = IGP instance unknown [This.doc] 12 = IGP instance unknown [This.doc]
13 = IGP instance advertisement not allowed by policy [This.doc] 13 = IGP instance advertisement not allowed by policy [This.doc]
14 = Component link identifier not valid [This.doc] 14 = Component link identifier not valid [This.doc]
15 = Unsupported component link identifier address [This.doc] 15 = Unsupported component link identifier address [This.doc]
family family
16 = Component link identifier missing [This.doc] 16 = Component link identifier missing [This.doc]
6. Acknowledgements 6. Acknowledgements
The authors would like to thank John Drake, Yakov Rekhter, Igor The authors would like to thank Lou Berger, Deborah Brungard, John
Bryskin, and Lucy Yong for their valuable discussions and comments. Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable
discussions and comments.
7. References 7. References
7.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.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
skipping to change at page 27, line 33 skipping to change at page 29, line ?
1600 Amphitheatre Pkwy 1600 Amphitheatre Pkwy
Mountain View, CA 94043 Mountain View, CA 94043
Email: rabbat@alum.mit.edu Email: rabbat@alum.mit.edu
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
United States of America United States of America
Email: arthi@juniper.net Email: arthi@juniper.net
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. Canada.
EMail: zali@cisco.com EMail: zali@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 32 change blocks. 
66 lines changed or deleted 84 lines changed or added

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