draft-ietf-mpls-p2mp-sig-requirement-00.txt   draft-ietf-mpls-p2mp-sig-requirement-01.txt 
Network Working Group Seisho Yasukawa (NTT) Network Working Group Seisho Yasukawa (NTT)
Internet Draft Editor Internet Draft Editor
Category: Informational Category: Informational
Expiration Date: May 2005 December 2004 Expiration Date: August 2005 February 2005
Signaling Requirements for Point to Multipoint Signaling Requirements for Point to Multipoint
Traffic Engineered MPLS LSPs Traffic Engineered MPLS LSPs
<draft-ietf-mpls-p2mp-sig-requirement-00.txt> <draft-ietf-mpls-p2mp-sig-requirement-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
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 2, line 8 skipping to change at page 2, line 8
It is intended that the requirements presented in this document are It is intended that the requirements presented in this document are
not limited to the requirements of packet switched networks, but also not limited to the requirements of packet switched networks, but also
encompass the requirements of L2SC, TDM, lambda and port switching encompass the requirements of L2SC, TDM, lambda and port switching
networks managed by Generalized MPLS (GMPLS) protocols. Protocol networks managed by Generalized MPLS (GMPLS) protocols. Protocol
solutions developed to meet the requirements set out in this document solutions developed to meet the requirements set out in this document
must attempt to be equally applicable to MPLS and GMPLS. must attempt to be equally applicable to MPLS and GMPLS.
Table of Contents Table of Contents
1. Introduction .................................................. 03 1. Introduction .................................................. 03
1.1 Non-Objectives ............................................ 05
2. Definitions ................................................... 06 2. Definitions ................................................... 06
2.1 Acronyms .................................................. 06 2.1 Acronyms .................................................. 06
2.2 Terminology ............................................... 06 2.2 Terminology ............................................... 06
2.2.1 Terminology for Partial LSPs ............................ 07 2.2.1 Terminology for Partial LSPs ......................... 07
2.3 Conventions ............................................... 09 2.3 Conventions ............................................... 08
3. Problem Statement ............................................. 09 3. Problem Statement ............................................. 08
3.1 Motivation ................................................ 09 3.1 Motivation ................................................ 08
3.2. Requirements Overview .................................... 09 3.2. Requirements Overview .................................... 09
4. Detailed requirements for P2MP TE extensions .................. 11 4. Detailed requirements for P2MP TE extensions .................. 11
4.1 P2MP LSP tunnels .......................................... 11 4.1 P2MP LSP tunnels .......................................... 11
4.2 P2MP explicit routing ..................................... 12 4.2 P2MP explicit routing ..................................... 11
4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes . 13 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes . 12
4.4 P2MP TE LSP establishment, teardown, and modification 4.4 P2MP TE LSP establishment, teardown, and modification
mechanisms ................................................ 14 mechanisms ................................................ 13
4.5 Fragmentation ............................................. 14 4.5 Fragmentation ............................................. 14
4.6 Failure Reporting and Error Recovery ...................... 15 4.6 Failure Reporting and Error Recovery ...................... 14
4.7 Record route of P2MP TE LSP tunnels ....................... 16 4.7 Record route of P2MP TE LSP tunnels ....................... 15
4.8 Call Admission Control (CAC) and QoS Control mechanism 4.8 Call Admission Control (CAC) and QoS Control mechanism
of P2MP TE LSPs ........................................... 16 of P2MP TE LSPs ........................................... 16
4.9 Variation of LSP Parameters ............................... 17 4.9 Variation of LSP Parameters ............................... 16
4.10 Re-optimization of P2MP TE LSPs .......................... 17 4.10 Re-optimization of P2MP TE LSPs .......................... 16
4.11 Tree Remerge ............................................. 18 4.11 Tree Remerge ............................................. 17
4.12 Data Duplication ......................................... 19 4.12 Data Duplication ......................................... 18
4.13 IPv4/IPv6 support ........................................ 19 4.13 IPv4/IPv6 support ........................................ 19
4.14 P2MP MPLS Label .......................................... 19 4.14 P2MP MPLS Label .......................................... 19
4.15 Routing advertisement of P2MP capability ................. 19 4.15 Routing advertisement of P2MP capability ................. 19
4.16 Multi-Area/AS LSP ........................................ 20 4.16 Multi-Area/AS LSP ........................................ 19
4.17 Multi-access LANs ........................................ 20 4.17 Multi-access LANs ........................................ 20
4.18 P2MP MPLS OAM ............................................ 21 4.18 P2MP MPLS OAM ............................................ 20
4.19 Scalability .............................................. 21 4.19 Scalability .............................................. 20
4.19.1 Absolute Limits ........................................ 22 4.19.1 Absolute Limits ..................................... 21
4.20 Backwards Compatibility .................................. 23 4.20 Backwards Compatibility .................................. 22
4.21 GMPLS .................................................... 24 4.21 GMPLS .................................................... 23
4.22 Requirements for Hierarchical P2MP TE LSPs ............... 25 4.22 Requirements for Hierarchical P2MP TE LSPs ............... 24
4.23 P2MP Crankback routing ................................... 25 4.23 P2MP Crankback routing ................................... 24
5. Security Considerations ....................................... 25 5. Security Considerations ....................................... 24
6. Acknowledgements .............................................. 25 6. Acknowledgements .............................................. 25
7. References .................................................... 26 7. References .................................................... 25
7.1 Normative References ...................................... 26 7.1 Normative References ...................................... 25
7.2 Informational References .................................. 26 7.2 Informational References .................................. 26
8. Editor's Address .............................................. 28 8. Editor's Address .............................................. 27
9. Authors' Addresses ............................................ 28 9. Authors' Addresses ............................................ 27
10. Intellectual Property Consideration .......................... 29 10. Intellectual Property Consideration .......................... 28
11. Full Copyright Statement ..................................... 30 11. Full Copyright Statement ..................................... 29
1. Introduction 1. Introduction
Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS
guarantees, resources optimization, and fast failure recovery, but is guarantees, resources optimization, and fast failure recovery, but is
limited to point-to-point (P2P) applications. Requirements have been limited to point-to-point (P2P) applications. Requirements have been
expressed for the provision of services over point-to-multipoint expressed for the provision of services over point-to-multipoint
(P2MP) traffic engineered tunnels and this clearly motivates (P2MP) traffic engineered tunnels and this clearly motivates
enhancements of the base MPLS-TE tool box in order to support P2MP enhancements of the base MPLS-TE tool box in order to support P2MP
MPLS-TE LSPs. MPLS-TE LSPs.
skipping to change at page 6, line 5 skipping to change at page 5, line 38
It is assumed that some information elements describing the P2MP TE It is assumed that some information elements describing the P2MP TE
LSP are known to the ingress LSR prior to LSP establishment. LSP are known to the ingress LSR prior to LSP establishment.
For example, the ingress LSRs knows the IP addresses that identify For example, the ingress LSRs knows the IP addresses that identify
the egress LSRs of the P2MP TE LSP. The mechanisms by which the the egress LSRs of the P2MP TE LSP. The mechanisms by which the
ingress LSR obtains this information is outside the scope of P2MP TE ingress LSR obtains this information is outside the scope of P2MP TE
signaling and so is not included in this document. Other documents signaling and so is not included in this document. Other documents
may complete the description of this function by providing may complete the description of this function by providing
automated, protocol-based ways of passing this information to the automated, protocol-based ways of passing this information to the
ingress LSR. ingress LSR.
The following are non-objectives of this document.
- Non-TE LSPs (such as per-hop, routing-based LSPs). - Non-TE LSPs (such as per-hop, routing-based LSPs).
- Discovery of egress leaves for a P2MP LSP - Discovery of egress leaves for a P2MP LSP
- Hierarchical P2MP LSPs - Hierarchical P2MP LSPs
- OAM for P2MP LSPs - OAM for P2MP LSPs
- Inter-area and inter-AS P2MP TE LSPs - Inter-area and inter-AS P2MP TE LSPs
- Applicability of P2MP MPLS TE LSPs to service scenarios - Applicability of P2MP MPLS TE LSPs to service scenarios
- Specific application or application requirements - Specific application or application requirements
skipping to change at page 17, line 22 skipping to change at page 16, line 36
Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] Any solution SHOULD also satisfy the DS-TE requirements [RFC3564]
and interoperate smoothly with current P2P DS-TE protocol and interoperate smoothly with current P2P DS-TE protocol
specifications. specifications.
Note that this requirement document does not make any assumption on Note that this requirement document does not make any assumption on
the type of bandwidth pool used for P2MP TE LSPs which can either be the type of bandwidth pool used for P2MP TE LSPs which can either be
shared with P2P TE LSP or be dedicated for P2MP use. shared with P2P TE LSP or be dedicated for P2MP use.
4.9 Variation of LSP Parameters 4.9 Variation of LSP Parameters
Various parameters to an LSP (such as priority, bandwidth, etc.) are Certain parameters (such as priority and bandwidth) are associated
signaled along each branch of the LSP. with an LSP. The parameters are installed by the signaling exchanges
associated with establishing and maintaining the LSP
Any solution MUST NOT allow for variance of these parameters. That Any solution MUST NOT allow for variance of these parameters within
is, a single P2MP LSP. That is:
- no attributes set and signaled by the ingress of a P2MP LSP may be - No attributes set and signaled by the ingress of a P2MP LSP may be
varied by downstream LSRs varied by downstream LSRs.
- there MUST be homogeneous QoS from the root to all leaves. - There MUST be homogeneous QoS from the root to all leaves of a
single P2MP LSP.
THIS IS A PROVISIONAL REQUIREMENT STILL OPEN FOR DISCUSSION. Variation of parameters may be allowed so long as it applies to the
whole LSP from ingress to all egresses.
4.10 Re-optimization of P2MP TE LSPs 4.10 Re-optimization of P2MP TE LSPs
The detection of a more optimal path (for example, one with a lower The detection of a more optimal path (for example, one with a lower
overall cost) is an example of a situation where P2MP TE LSP overall cost) is an example of a situation where P2MP TE LSP
re-routing may be required. While re-routing is in progress, an re-routing may be required. While re-routing is in progress, an
important requirement is avoiding double bandwidth reservation important requirement is avoiding double bandwidth reservation
(over the common parts between the old and new LSP) thorough the use (over the common parts between the old and new LSP) thorough the use
of resource sharing. of resource sharing.
skipping to change at page 18, line 12 skipping to change at page 17, line 25
sub-P2MP tree without impacting the data on all of the other parts sub-P2MP tree without impacting the data on all of the other parts
of the P2MP tree. of the P2MP tree.
The solution SHOULD allow for make-before-break re-optimization of The solution SHOULD allow for make-before-break re-optimization of
any subdivision of the P2MP LSP (S2L sub-tree, S2X sub-LSP, S2L any subdivision of the P2MP LSP (S2L sub-tree, S2X sub-LSP, S2L
sub-LSP, X2L sub-tree, B2L sub-tree, X2L tree, or B2L tree) with no sub-LSP, X2L sub-tree, B2L sub-tree, X2L tree, or B2L tree) with no
impact on the rest of the P2MP LSP (no label reallocation, no change impact on the rest of the P2MP LSP (no label reallocation, no change
in identifiers, etc.). in identifiers, etc.).
The solution SHOULD also provide the ability for the ingress LSR to The solution SHOULD also provide the ability for the ingress LSR to
have a strict control on the re-optimization process. have a strict control on the re-optimization process. The ingress
Such re-optimization MAY be initiated by the sub-tree root branch LSR SHOULD be able to limit all re-optimization to be
node (that is, the branch node MAY setup a new sub-tree, then splice source-initiated.
traffic on the new subtree and delete the former sub-tree).
THE REQUIREMENT FOR RE-OPTIMIZATION BY SUB-TREE ROOT BRANCH IS Where sub-tree re-optimization is allowed by the ingress LSR, such
STILL OPEN FOR DISCUSSION re-optimization MAY be initiated by a downstream LSR that is the
root of the sub-tree that is to be re-optimized. Sub-tree
re-optimization initiated by a downstream LSR MUST be carried out
with the same regard to minimizing the hit on active traffic as
was described above for other re-optimization.
4.11 Tree Remerge 4.11 Tree Remerge
It is possible for a single transit LSR to receive multiple It is possible for a single transit LSR to receive multiple
signaling messages for the same P2MP LSP but for different signaling messages for the same P2MP LSP but for different
sets of destinations. These messages may be received from the sets of destinations. These messages may be received from the
same or different upstream nodes and may need to be passed on same or different upstream nodes and may need to be passed on
to the same or different downstream nodes. to the same or different downstream nodes.
This situation may arise as the result of the signaling solution This situation may arise as the result of the signaling solution
skipping to change at page 18, line 41 skipping to change at page 18, line 9
reoptimization (section 4.10), or as a result of signaling reoptimization (section 4.10), or as a result of signaling
message fragmentation (section 4.5). message fragmentation (section 4.5).
It is even possible that it is necessary to construct distinct It is even possible that it is necessary to construct distinct
upstream branches in order to achieve the correct label choices upstream branches in order to achieve the correct label choices
in certain switching technologies managed by GMPLS (for example, in certain switching technologies managed by GMPLS (for example,
photonic cross-connects where the selection of a particular photonic cross-connects where the selection of a particular
lambda for the downstream branches is only available on different lambda for the downstream branches is only available on different
upstream switches). upstream switches).
The solution MUST handle the case where multiple signaling The solution MUST support the case where of multiple signaling
messages for the same P2MP LSP are received at a single transit messages for the same P2MP LSP are received at a single transit
LSR with the end result of all receivers being added to the LSR and refer to the same upstream interface. In this case the
P2MP LSP. result of the protocol procedures SHOULD be a single data flow
on the upstream interface.
THIS REQUIREMENT IS STILL UNDER DISCUSSION The solution SHOULD support the case where multiple signaling
messages for the same P2MP LSP are received at a single transit
LSR and refer to different upstream interfaces, and where each
signaling message results in the use of different downstream
interfaces. This case represents data flows that cross at the LSR
but which do not merge.
The solution MAY support the case where multiple signaling
messages for the same P2MP LSP are received at a single transit
LSR and refer to different upstream interfaces, and where the
downstream interfaces are shared across the received signaling
messages. This case represents the merging of data flows. A
solution that supports this case MUST ensure that data is not
replicated on the downstream interfaces.
An alternative to supporting this last case is for the signaling
protocol to indicate an error such that the merge may be
resolved by the upstream LSRs.
4.12 Data Duplication 4.12 Data Duplication
Data duplication refers to the receipt by any recipient of duplicate Data duplication refers to the receipt by any recipient of duplicate
instances of the data. In a packet environment this means the instances of the data. In a packet environment this means the
receipt of duplicate packets - although this should be a benign (if receipt of duplicate packets - although this should be a benign (if
inefficient) situation, it may be catastrophic in certain existing inefficient) situation, it may be catastrophic in certain existing
and deployed applications. In a non-packet environment this means and deployed applications. In a non-packet environment this means
the duplication in time of some part of the signal that may lead to the duplication in time of some part of the signal that may lead to
the replication of data or to the scrambling of data. the replication of data or to the scrambling of data.
skipping to change at page 21, line 10 skipping to change at page 20, line 31
replicated data must be sent through the same port and carried on replicated data must be sent through the same port and carried on
the same segment. Thus, a solution SHOULD provide a mechanism for a the same segment. Thus, a solution SHOULD provide a mechanism for a
branch node to send a single copy of the data onto a multi-access branch node to send a single copy of the data onto a multi-access
network and reach multiple (adjacent) downstream nodes. network and reach multiple (adjacent) downstream nodes.
4.18 P2MP MPLS OAM 4.18 P2MP MPLS OAM
Management of P2MP LSPs is as important as the management of P2P Management of P2MP LSPs is as important as the management of P2P
LSPs. LSPs.
The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE The MPLS and GMPLS MIB modules will be enhanced to provide P2MP TE
LSP management. LSP management in line with whatever signaling solutions are
developed.
In order to facilitate correct management, P2MP TE LSPs MUST have In order to facilitate correct management, P2MP TE LSPs MUST have
unique identifiers. unique identifiers since otherwise it is impossible to determine
which LSP is being managed.
OAM facilities will have special demands in P2MP environments OAM facilities will have special demands in P2MP environments
especially within the context of tracing the paths and connectivity especially within the context of tracing the paths and connectivity
of P2MP TE LSPs. The precise requirements and mechanisms for OAM are of P2MP TE LSPs. Further and precise requirements and mechanisms for
out of the scope of this document. It is expected that a separate OAM are out of the scope of this document. It is expected that
document will cover these requirements. separate documents will cover these requirements and mechanisms.
4.19 Scalability 4.19 Scalability
Scalability is a key requirement in P2MP MPLS systems. Solutions Scalability is a key requirement in P2MP MPLS systems. Solutions
MUST be designed to scale well with an increase in the number of any MUST be designed to scale well with an increase in the number of any
of the following: of the following:
- the number of recipients - the number of recipients
- the number of branch points - the number of branch points
- the number of branches. - the number of branches.
skipping to change at page 26, line 5 skipping to change at page 25, line 10
issues are similar to security issues for IP multicast. issues are similar to security issues for IP multicast.
It is a requirement that documents offering solutions for P2MP LSPs It is a requirement that documents offering solutions for P2MP LSPs
MUST have detailed security sections. MUST have detailed security sections.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank George Swallow, Ichiro Inoue, Dean The authors would like to thank George Swallow, Ichiro Inoue, Dean
Cheng, Lou Berger and Eric Rosen for their review and suggestions. Cheng, Lou Berger and Eric Rosen for their review and suggestions.
Thanks to Loa Andersson for his help resolving the final issues in
this document.
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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
skipping to change at page 28, line 45 skipping to change at page 28, line 4
3-20-2 Nishi Shinjuku, Shinjuku-ku, 3-20-2 Nishi Shinjuku, Shinjuku-ku,
Tokyo 163-1421, Tokyo 163-1421,
Japan Japan
Email: y.kamite@ntt.com Email: y.kamite@ntt.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
Alan Kullberg Alan Kullberg
Motorola Computer Group Motorola Computer Group
120 Turnpike Rd. 120 Turnpike Rd.
Southborough, MA 01772 Southborough, MA 01772
Email: alan.kullberg@motorola.com Email: alan.kullberg@motorola.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Markus Jork Markus Jork
Avici Systems Quarry Technologies
101 Billerica Avenue 8 New England Executive Park
N. Billerica, MA 01862 Burlington, MA 01803
Phone: +1 978 964 2142 EMail: mjork@quarrytech.com
Email: mjork@avici.com
Andrew G. Malis Andrew G. Malis
Tellabs Tellabs
2730 Orchard Parkway 2730 Orchard Parkway
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 383 7223 Phone: +1 408 383 7223
Email: andy.malis@tellabs.com Email: andy.malis@tellabs.com
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
skipping to change at page 30, line 13 skipping to change at page 29, line 13
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
draft-ietf-mpls-p2mp-sig-requirement-00.txt
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/