draft-ietf-mpls-p2mp-sig-requirement-01.txt   draft-ietf-mpls-p2mp-sig-requirement-02.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: August 2005 February 2005 Expiration Date: August 2005 April 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-01.txt> <draft-ietf-mpls-p2mp-sig-requirement-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of 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 other groups may also distribute working documents as
Internet-Drafts. Internet-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."
skipping to change at page 1, line 46 skipping to change at page 1, line 46
This document presents a set of requirements for the establishment This document presents a set of requirements for the establishment
and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE)
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
There is no intent to specify solution specific details nor There is no intent to specify solution specific details nor
application specific requirements in this document. application specific requirements in this document.
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 Layer two Switching (L2SC), Time
networks managed by Generalized MPLS (GMPLS) protocols. Protocol Division Multiplexing (TDM), lambda and port switching networks
solutions developed to meet the requirements set out in this document managed by Generalized MPLS (GMPLS) protocols. Protocol solutions
must attempt to be equally applicable to MPLS and GMPLS. developed to meet the requirements set out in this document 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 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 ............................................... 08 2.3 Conventions ............................................... 08
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.11 Tree Remerge ............................................. 17 4.11 Tree Remerge ............................................. 17
4.12 Data Duplication ......................................... 18 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 ........................................ 19 4.16 Multi-Area/AS LSP ........................................ 19
4.17 Multi-access LANs ........................................ 20 4.17 Multi-access LANs ........................................ 20
4.18 P2MP MPLS OAM ............................................ 20 4.18 P2MP MPLS OAM ............................................ 20
4.19 Scalability .............................................. 20 4.19 Scalability .............................................. 20
4.19.1 Absolute Limits ..................................... 21 4.19.1 Absolute Limits ..................................... 21
4.20 Backwards Compatibility .................................. 22 4.20 Backwards Compatibility .................................. 23
4.21 GMPLS .................................................... 23 4.21 GMPLS .................................................... 23
4.22 Requirements for Hierarchical P2MP TE LSPs ............... 24 4.22 Requirements for Hierarchical P2MP TE LSPs ............... 24
4.23 P2MP Crankback routing ................................... 24 4.23 P2MP Crankback routing ................................... 24
5. Security Considerations ....................................... 24 5. Security Considerations ....................................... 24
6. Acknowledgements .............................................. 25 6. IANA Considerations ........................................... 25
7. References .................................................... 25 7. Acknowledgements .............................................. 25
7.1 Normative References ...................................... 25 8. References .................................................... 25
7.2 Informational References .................................. 26 8.1 Normative References ...................................... 25
8. Editor's Address .............................................. 27 8.2 Informational References .................................. 26
9. Authors' Addresses ............................................ 27 9. Editor's Address .............................................. 27
10. Intellectual Property Consideration .......................... 28 10. Authors' Addresses ........................................... 27
11. Full Copyright Statement ..................................... 29 11. Intellectual Property Consideration .......................... 28
12. 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
limited to point-to-point (P2P) applications. Requirements have been is limited to point-to-point (P2P) applications. Requirements have
expressed for the provision of services over point-to-multipoint been expressed for the provision of services over
(P2MP) traffic engineered tunnels and this clearly motivates point-to-multipoint (P2MP) traffic engineered tunnels and this
enhancements of the base MPLS-TE tool box in order to support P2MP clearly motivates enhancements of the base MPLS-TE tool box in order
MPLS-TE LSPs. to support P2MP MPLS-TE LSPs.
[RFC2702] specifies requirements for traffic engineering over MPLS. [RFC2702] specifies requirements for traffic engineering over MPLS.
It describes traffic engineering in some detail, and those It describes traffic engineering in some detail, and those
definitions and objectives are equally applicable to traffic definitions and objectives are equally applicable to traffic
engineering in a point-to-multipoint service environment. They are engineering in a point-to-multipoint service environment. They are
not repeated here, but it is assumed that the reader is fully not repeated here, but it is assumed that the reader is fully
familiar with them. familiar with them.
[RFC2702] also explains how MPLS is particularly suited to traffic [RFC2702] also explains how MPLS is particularly suited to traffic
engineering, and presents the following eight reason. engineering, and presents the following eight reason.
1. Explicit label switched paths which are not constrained by 1. Explicit label switched paths which are not constrained by
the destination based forwarding paradigm can be easily created the destination based forwarding paradigm can be easily
through manual administrative action or through automated created through manual administrative action or through
action by the underlying protocols. automated action by the underlying protocols.
2. LSPs can potentially be efficiently maintained. 2. LSPs can potentially be efficiently maintained.
3. Traffic trunks can be instantiated and mapped onto LSPs. 3. Traffic trunks can be instantiated and mapped onto LSPs.
4. A set of attributes can be associated with traffic trunks 4. A set of attributes can be associated with traffic trunks
which modulate their behavioral characteristics. which modulate their behavioral characteristics.
5. A set of attributes can be associated with resources which 5. A set of attributes can be associated with resources which
constrain the placement of LSPs and traffic trunks across constrain the placement of LSPs and traffic trunks across
them. them.
6. MPLS allows for both traffic aggregation and disaggregation 6. MPLS allows for both traffic aggregation and disaggregation
whereas classical destination only based IP forwarding whereas classical destination only based IP forwarding
permits only aggregation. permits only aggregation.
7. It is relatively easy to integrate a "constraint-based routing" 7. It is relatively easy to integrate a "constraint-based
framework with MPLS. routing" framework with MPLS.
8. A good implementation of MPLS can offer significantly lower 8. A good implementation of MPLS can offer significantly lower
overhead than competing alternatives for Traffic Engineering. overhead than competing alternatives for Traffic Engineering.
These points are equally applicable to point-to-multipoint These points are equally applicable to point-to-multipoint
traffic engineering. Points 1. and 7. are particularly important. traffic engineering. Points 1. and 7. are particularly important.
That is, the traffic flow for a point-to-multipoint LSP is not That is, the traffic flow for a point-to-multipoint LSP is not
constrained to the path or paths that it would follow during constrained to the path or paths that it would follow during
multicast routing or shortest path destination-based routing, but multicast routing or shortest path destination-based routing, but
can be explicitly controlled through manual or automated action. can be explicitly controlled through manual or automated action.
Further, the explicit paths that are used may be computed using Further, the explicit paths that are used may be computed using
algorithms based on a variety of constraints to produce all manner of algorithms based on a variety of constraints to produce all manner
tree shapes. For example, an explicit path may be cost-based of tree shapes. For example, an explicit path may be cost-based
[STEINER], shortest path, QoS-based, or may use some fair-cost QoS [STEINER], shortest path, QoS-based, or may use some fair-cost QoS
algorithm. algorithm.
[RFC2702] also describes the functional capabilities required to [RFC2702] also describes the functional capabilities required to
fully support Traffic Engineering over MPLS in large networks. fully support Traffic Engineering over MPLS in large networks.
1. A set of attributes associated with traffic trunks which 1. A set of attributes associated with traffic trunks which
collectively specify their behavioral characteristics. collectively specify their behavioral characteristics.
2. A set of attributes associated with resources which constrain 2. A set of attributes associated with resources which constrain
skipping to change at page 4, line 33 skipping to change at page 4, line 33
tightly integrated together. tightly integrated together.
These basic requirements should also be supported by P2MP traffic These basic requirements should also be supported by P2MP traffic
engineering. engineering.
This document presents a set of requirements for This document presents a set of requirements for
Point-to-Multipoint(P2MP) Traffic Engineering (TE) extensions to Point-to-Multipoint(P2MP) Traffic Engineering (TE) extensions to
Multiprotocol Label Switching (MPLS). It specifies functional Multiprotocol Label Switching (MPLS). It specifies functional
requirements for solutions to deliver P2MP TE LSPs. requirements for solutions to deliver P2MP TE LSPs.
It is intended that solutions that specify procedures for P2MP TE LSP It is intended that solutions that specify procedures for P2MP TE
setup satisfy these requirements. There is no intent to specify LSP setup satisfy these requirements. There is no intent to specify
solution specific details nor application specific requirements in solution specific details nor application specific requirements in
this document. this document.
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 not limited to the requirements of packet switched networks, but
also encompass the requirements of TDM, lambda and port switching also encompass the requirements of 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 solutions developed to meet the requirements set out in this
document must attempt to be equally applicable to MPLS and GMPLS. document must attempt to be equally applicable to MPLS and GMPLS.
Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE
LSPs so new mechanisms must be developed. This should be achieved LSPs so new mechanisms must be developed. This should be achieved
with maximum re-use of existing MPLS protocols. with maximum re-use of existing MPLS protocols.
Note that there is a separation between routing and signaling in Note that there is a separation between routing and signaling in
MPLS TE. In particular, the path of the MPLS TE LSP is determined by MPLS TE. In particular, the path of the MPLS TE LSP is determined by
performing a constraint-based computation (such as CSPF) on a traffic performing a constraint-based computation (such as CSPF) on a
engineering database (TED). The contents of the TED may be collected traffic engineering database (TED). The contents of the TED may be
through a variety of mechanism - extensions to the IGPs are a collected through a variety of mechanism - extensions to the IGPs
popular mechanism for P2P MPLS TE. are a popular mechanism for P2P MPLS TE.
This document focuses on requirements for establishing and This document focuses on requirements for establishing and
maintaining P2MP MPLS TE LSPs through signaling protocols; and maintaining P2MP MPLS TE LSPs through signaling protocols; and
routing protocols are out of scope. No assumptions are made about how routing protocols are out of scope. No assumptions are made about
the TED used as the basis for path computations for P2MP LSPs is how the TED used as the basis for path computations for P2MP LSPs is
formed. formed.
A P2MP TE LSP will be set up with TE constraints and will allow A P2MP TE LSP will be set up with TE constraints and will allow
efficient packet or data replication at various branching points in efficient packet or data replication at various branching points in
the network. Note that the notion of "efficient" packet replication the network. Note that the notion of "efficient" packet replication
is relative and may have different meanings depending on the is relative and may have different meanings depending on the
objectives (see section 4.2). objectives (see section 4.2).
P2MP TE LSP setup mechanisms MUST include the ability to add/remove P2MP TE LSP setup mechanisms MUST include the ability to add/remove
receivers to/from an existing P2MP TE LSP. receivers to/from an existing P2MP TE LSP.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
Hence, to provide P2MP MPLS TE services in a fully efficient manner Hence, to provide P2MP MPLS TE services in a fully efficient manner
it is necessary to specify specific requirements. These requirements it is necessary to specify specific requirements. These requirements
can then be used to define mechanisms for the use of existing can then be used to define mechanisms for the use of existing
protocols and/or extensions to existing protocols and/or new protocols and/or extensions to existing protocols and/or new
protocols. protocols.
3.2. Requirements Overview 3.2. Requirements Overview
This document states basic requirements for the setup of P2MP TE This document states basic requirements for the setup of P2MP TE
LSPs. The requirements apply to the signaling techniques only, and no LSPs. The requirements apply to the signaling techniques only, and
assumptions are made about which routing protocols are run within the no assumptions are made about which routing protocols are run within
network, nor about how the information that is used to construct the the network, nor about how the information that is used to construct
Traffic Engineering Database (TED) is distributed. These factors are the Traffic Engineering Database (TED) is distributed. These factors
out of the scope of this document. are out of the scope of this document.
A P2MP TE LSP path will be computed taking into account various A P2MP TE LSP path will be computed taking into account various
constraints such as bandwidth, affinities, required level of constraints such as bandwidth, affinities, required level of
protection and so on. The solution MUST allow for the computation protection and so on. The solution MUST allow for the computation
of P2MP TE LSP paths satisfying constraints with the objective of of P2MP TE LSP paths satisfying constraints with the objective of
supporting various optimization criteria such as delays, bandwidth supporting various optimization criteria such as delays, bandwidth
consumption in the network, or any other combinations. This is likely consumption in the network, or any other combinations. This is
to require the presence of a TED, as well as the ability to signal likely to require the presence of a TED, as well as the ability to
the explicit path of an LSP. signal the explicit path of an LSP.
A desired requirement is also to maximize the re-use of existing A desired requirement is also to maximize the re-use of existing
MPLS TE techniques and protocols where doing so does not adversely MPLS TE techniques and protocols where doing so does not adversely
impact the function, simplicity or scalability of the solution. impact the function, simplicity or scalability of the solution.
This document does not restrict the choice of signaling protocol This document does not restrict the choice of signaling protocol
used to set up a P2MP TE LSP, but it should be noted that [RFC3468] used to set up a P2MP TE LSP, but it should be noted that [RFC3468]
states states
... the consensus reached by the Multiprotocol Label Switching ... the consensus reached by the Multiprotocol Label Switching
(MPLS) Working Group within the IETF to focus its efforts on (MPLS) Working Group within the IETF to focus its efforts on
skipping to change at page 12, line 22 skipping to change at page 12, line 22
Steiner P2MP tree SPF P2MP tree Steiner P2MP tree SPF P2MP tree
Figure 4 Examples of P2MP TE LSP topology Figure 4 Examples of P2MP TE LSP topology
One example is the Steiner P2MP tree (Cost minimum P2MP tree) One example is the Steiner P2MP tree (Cost minimum P2MP tree)
[STEINER]. This P2MP tree is suitable for constructing a cost [STEINER]. This P2MP tree is suitable for constructing a cost
minimum P2MP tree so as to minimize the bandwidth consumption in minimum P2MP tree so as to minimize the bandwidth consumption in
the core. To realize this P2MP tree, several intermediate LSRs must the core. To realize this P2MP tree, several intermediate LSRs must
be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G,
H, I, J and K in the figure 4). This means that the LSRs must perform H, I, J and K in the figure 4). This means that the LSRs must
both label swapping and popping at the same time. Therefore, the P2MP perform both label swapping and popping at the same time. Therefore,
TE solution MUST support a mechanism that can setup this kind of bud the P2MP TE solution MUST support a mechanism that can setup this
LSR between an ingress LSR and egress LSRs. Note that this includes kind of bud LSR between an ingress LSR and egress LSRs. Note that
constrained Steiner trees that allow for the computation of a minimal this includes constrained Steiner trees that allow for the
cost trees with some other constraints such as a bounded delay computation of a minimal cost trees with some other constraints such
between the source and every receiver. as a bounded delay between the source and every receiver.
Another example is a CSPF (Constraint Shortest Path First) P2MP Another example is a CSPF (Constraint Shortest Path First) P2MP
tree. By some metric (which can be set upon any specific criteria tree. By some metric (which can be set upon any specific criteria
like the delay, bandwidth, a combination of those), one can like the delay, bandwidth, a combination of those), one can
calculate a shortest path P2MP tree. This P2MP tree is suitable for calculate a shortest path P2MP tree. This P2MP tree is suitable for
carrying real time traffic. carrying real time traffic.
The solution MUST allow the operator to make use of any tree The solution MUST allow the operator to make use of any tree
computation technique. In the former case an efficient/optimal tree computation technique. In the former case an efficient/optimal tree
is defined as a minimal cost tree (Steiner tree) whereas in the is defined as a minimal cost tree (Steiner tree) whereas in the
skipping to change at page 13, line 31 skipping to change at page 13, line 31
specified at the ingress where sufficient information exists to specified at the ingress where sufficient information exists to
allow the full tree to be computed. allow the full tree to be computed.
In all cases, the egress nodes of the P2MP TE LSP must be fully In all cases, the egress nodes of the P2MP TE LSP must be fully
specified. specified.
In case of a tree being computed by some downstream LSRs (e.g. the In case of a tree being computed by some downstream LSRs (e.g. the
case of hops specified as loose hops), the solution MUST provide case of hops specified as loose hops), the solution MUST provide
the ability for the ingress LSR of the P2MP TE LSP to learn the full the ability for the ingress LSR of the P2MP TE LSP to learn the full
P2MP tree. Note that this requirement MAY be relaxed in some P2MP tree. Note that this requirement MAY be relaxed in some
environments (e.g. Inter-AS) where confidentiality must be preserved. environments (e.g. Inter-AS) where confidentiality must be
preserved.
4.4 P2MP TE LSP establishment, teardown, and modification mechanisms 4.4 P2MP TE LSP establishment, teardown, and modification mechanisms
The P2MP TE solution MUST support establishment, maintenance and The P2MP TE solution MUST support establishment, maintenance and
teardown of P2MP TE LSPs in a scalable manner. This MUST include teardown of P2MP TE LSPs in a scalable manner. This MUST include
both the existence of very many LSPs at once, and the existence of both the existence of very many LSPs at once, and the existence of
very many destinations for a single P2MP LSP. very many destinations for a single P2MP LSP.
In addition to P2MP TE LSP establishment and teardown mechanism, it In addition to P2MP TE LSP establishment and teardown mechanism, it
SHOULD implement partial P2MP tree modification mechanism. SHOULD implement partial P2MP tree modification mechanism.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
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
Certain parameters (such as priority and bandwidth) are associated Certain parameters (such as priority and bandwidth) are associated
with an LSP. The parameters are installed by the signaling exchanges with an LSP. The parameters are installed by the signaling
associated with establishing and maintaining the LSP exchanges associated with establishing and maintaining the LSP.
Any solution MUST NOT allow for variance of these parameters within Any solution MUST NOT allow for variance of these parameters within
a single P2MP LSP. That 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
varied by downstream LSRs. be varied by downstream LSRs.
- There MUST be homogeneous QoS from the root to all leaves of a - There MUST be homogeneous QoS from the root to all leaves of a
single P2MP LSP. single P2MP LSP.
Variation of parameters may be allowed so long as it applies to the Variation of parameters may be allowed so long as it applies to the
whole LSP from ingress to all egresses. 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
skipping to change at page 18, line 49 skipping to change at page 18, line 49
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.
Data duplication may legitimately arise in various scenarios Data duplication may legitimately arise in various scenarios
including re-optimization of active LSPs as described in the including re-optimization of active LSPs as described in the
previous section, and protection of LSPs. Thus, it is impractical to previous section, and protection of LSPs. Thus, it is impractical to
regulate against data duplication in this document. regulate against data duplication in this document.
Instead, the solution MUST provide a mechanism to resolve, limit or Instead, the solution:
avoid data duplication at either or both of: - SHOULD limit to transitory conditions only the cases where
- the point at which the data path diverges network bandwidth is wasted by the existence of duplicate
- the point at which the data paths converge. delivery paths.
- MUST limit the cases of delivery of duplicate data to an
THE EXTENT TO WHICH DATA DUPLICATION MAY BE TOLERATED (in time or in application to error cases or rare transitory conditions.
a count of bits or packets) IS FOR FURTHER STUDY.
4.13 IPv4/IPv6 support 4.13 IPv4/IPv6 support
Any P2MP TE solution MUST be equally applicable to IPv4 and IPv6. Any P2MP TE solution MUST be equally applicable to IPv4 and IPv6.
4.14 P2MP MPLS Label 4.14 P2MP MPLS Label
A P2MP TE solution MUST support establishment of both P2P and P2MP A P2MP TE solution MUST support establishment of both P2P and P2MP
TE LSPs and MUST NOT impede the operation of P2P TE LSPs within the TE LSPs and MUST NOT impede the operation of P2P TE LSPs within the
same network. A P2MP TE solution MUST be specified in such a way same network. A P2MP TE solution MUST be specified in such a way
skipping to change at page 21, line 8 skipping to change at page 21, line 8
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.
Both scalability of performance and operation MUST be considered. Both scalability of performance and operation MUST be considered.
Key considerations SHOULD include: Key considerations MUST include:
- the amount of refresh processing associated with maintaining - the amount of refresh processing associated with maintaining
a P2MP TE LSP. a P2MP TE LSP.
- the amount of protocol state that must be maintained by ingress - the amount of protocol state that must be maintained by ingress
and transit LSRs along a P2MP tree. and transit LSRs along a P2MP tree.
- the number of protocol messages required to set up or tear down a - the number of protocol messages required to set up or tear down a
P2MP LSP as a function of the number of egress LSRs. P2MP LSP as a function of the number of egress LSRs.
- the number of protocol messages required to repair a P2MP LSP - the number of protocol messages required to repair a P2MP LSP
after failure or perform make-before-break. after failure or perform make-before-break.
- the amount of protocol information transmitted to manage - the amount of protocol information transmitted to manage
a P2MP TE LSP (i.e. the message size). a P2MP TE LSP (i.e. the message size).
- the amount of potential routing extensions. - the amount of potential routing extensions.
- the amount of additional control plane processing required in
the network to detect whether an add/delete of a new branch is
required, and in particular, the amount of processing in steady
state when no add/delete is requested
- the amount of control plane processing required by the ingress, - the amount of control plane processing required by the ingress,
transit and egress LSRs to add/delete a branch LSP to/from an transit and egress LSRs to add/delete a branch LSP to/from an
existing P2MP LSP. existing P2MP LSP.
It is expected that the applicability of each solution will be It is expected that the applicability of each solution will be
evaluated with regards to the aforementioned scalability criteria. evaluated with regards to the aforementioned scalability criteria.
4.19.1 Absolute Limits 4.19.1 Absolute Limits
THIS IS SECTION DESCRIBES PROVISIONAL REQUIREMENTS STILL OPEN FOR
DISCUSSION.
In order to achieve the best solution for the problem space it is In order to achieve the best solution for the problem space it is
helpful to clarify the boundaries for P2MP TE LSPs. helpful to clarify the boundaries for P2MP TE LSPs.
- Number of recipients. - Number of recipients.
A P2MP TE LSP MUST reduce to similar scaling properties as a P2P A P2MP TE LSP MUST reduce to similar scaling properties as a P2P
LSP when the number of recipients reduces to one. LSP when the number of recipients reduces to one.
It is important to classify the problem as a Traffic Engineering It is important to classify the problem as a Traffic Engineering
problem. It is anticipated that the initial deployments of P2MP TE problem. It is anticipated that the initial deployments of P2MP TE
LSPs may be limited to only several hundred recipients, but also LSPs will be limited to a maximum of around a hundred recipients,
that future deployments may require significantly larger numbers. but that medium term deployments may increase this to several
hundred, and that future deployments may require significantly
larger numbers.
An acceptable solution, therefore, is one that scales linearly An acceptable solution, therefore, is one that scales linearly
with the number of recipients. with the number of recipients.
Solutions that scale worse than linear (that is, exponential or Solutions that scale worse than linear (that is, exponential or
polynomial) are not acceptable whatever the number of recipients polynomial) are not acceptable whatever the number of recipients
they could support they could support
- Number of branch points. - Number of branch points.
Solutions MUST support all possibilities from one extreme of a Solutions MUST support all possibilities from one extreme of a
single branch point that forks to all leaves on a separate branch, single branch point that forks to all leaves on a separate branch,
to the greatest number of branch points which is (n-1) for n to the greatest number of branch points which is (n-1) for n
recipients. Assumptions MUST NOT be made in the solution regarding recipients. Assumptions MUST NOT be made in the solution regarding
which topology is more common, and the solution MUST be designed which topology is more common, and the solution MUST be designed
to ensure scalability in all topologies. to ensure scalability in all topologies.
- Dynamics of P2MP tree. - Dynamics of P2MP tree.
Recall that the mechanisms for determining which recipients should Recall that the mechanisms for determining which recipients should
skipping to change at page 22, line 16 skipping to change at page 22, line 19
which topology is more common, and the solution MUST be designed which topology is more common, and the solution MUST be designed
to ensure scalability in all topologies. to ensure scalability in all topologies.
- Dynamics of P2MP tree. - Dynamics of P2MP tree.
Recall that the mechanisms for determining which recipients should Recall that the mechanisms for determining which recipients should
be added to an LSP, and for adding and removing recipients from be added to an LSP, and for adding and removing recipients from
that group are out of the scope of this document. Nevertheless, it that group are out of the scope of this document. Nevertheless, it
is useful to understand the expected rates of arrival and is useful to understand the expected rates of arrival and
departure of recipients since this can impact the selection of departure of recipients since this can impact the selection of
solution techniques. solution techniques.
Again, it must be recalled that this document is limited to Traffic Again, it must be recalled that this document is limited to
Engineering, and in this model the rate of change of recipients Traffic Engineering, and in this model the rate of change of
may be expected to be lower than in an IP multicast group. recipients may be expected to be lower than in an IP multicast
group.
Although the absolute number of recipients coming and going is the Although the absolute number of recipients coming and going is the
important element for determining the scalability of a solution, important element for determining the scalability of a solution,
it may be noted that a percentage may be a more comprehensible it may be noted that a percentage may be a more comprehensible
measure but that this is not as significant for LSPs with a small measure but that this is not as significant for LSPs with a small
number of recipients. number of recipients.
A working figure for an established P2MP TE LSP is less than 10% A working figure for an established P2MP TE LSP is less than 10%
churn per day. That is, a relatively slow rate of churn. churn per day. That is, a relatively slow rate of churn.
We could say that a P2MP LSP would be shared by multiple multicast We could say that a P2MP LSP would be shared by multiple multicast
groups and dynamics of P2MP LSP would be relatively small. groups and dynamics of P2MP LSP would be relatively small.
Considering applicability that P2MP LSP to use L2 multi-access Considering applicability that P2MP LSP to use L2 multi-access
skipping to change at page 23, line 39 skipping to change at page 23, line 44
working groups. working groups.
Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or
non-PSC TE-LSPs MUST be backward and forward compatible with the non-PSC TE-LSPs MUST be backward and forward compatible with the
other features of GMPLS including: other features of GMPLS including:
- control and data plane separation (IF_ID RSVP_HOP and IF_ID - control and data plane separation (IF_ID RSVP_HOP and IF_ID
ERROR_SPEC), ERROR_SPEC),
- full support of numbered and unnumbered TE links (see [RFC 3477] - full support of numbered and unnumbered TE links (see [RFC 3477]
and [GMPLS-ROUTE]), and [GMPLS-ROUTE]),
- use of the GENERALIZED_LABEL_REQUEST, the GENERALIZED_LABEL - use of the GENERALIZED_LABEL_REQUEST, the GENERALIZED_LABEL (C-Type
(C-Type 2 and 3), the SUGGESTED_LABEL and the RECOVERY_LABEL, 2 and 3), the SUGGESTED_LABEL and the RECOVERY_LABEL, in
in conjunction with the LABEL_SET and the ACCEPTABLE_LABEL_SET conjunction with the LABEL_SET and the ACCEPTABLE_LABEL_SET object,
object,
- processing of the ADMIN_STATUS object, - processing of the ADMIN_STATUS object,
- processing of the PROTECTION object, - processing of the PROTECTION object,
- support of Explicit Label Control, - support of Explicit Label Control,
- processing of the Path_State_Removed Flag, - processing of the Path_State_Removed Flag,
- handling of Graceful Deletion procedures. - handling of Graceful Deletion procedures.
- E2E and Segment Recovery procedures. - E2E and Segment Recovery procedures.
- support of Graceful Restart - support of Graceful Restart.
In addition, since non-PSC TE-LSPs may have to be processed in In addition, since non-PSC TE-LSPs may have to be processed in
environments where the "P2MP capability" could be limited, specific environments where the "P2MP capability" could be limited, specific
constraints may also apply during the P2MP TE Path computation. constraints may also apply during the P2MP TE Path computation.
Being technology specific, these constraints are outside the scope Being technology specific, these constraints are outside the scope
of this document. However, technology independent constraints of this document. However, technology independent constraints
(i.e. constraints that are applicable independently of the LSP (i.e. constraints that are applicable independently of the LSP
class) SHOULD be allowed during P2MP TE LSP message processing. class) SHOULD be allowed during P2MP TE LSP message processing.
It has to be emphasized that path computation and management It has to be emphasized that path computation and management
techniques shall be as close as possible to those being used for techniques shall be as close as possible to those being used for
skipping to change at page 25, line 5 skipping to change at page 25, line 5
It should be noted that P2MP signaling mechanisms built on P2P It should be noted that P2MP signaling mechanisms built on P2P
RSVP-TE signaling are likely to inherit all of the security RSVP-TE signaling are likely to inherit all of the security
techniques and problems associated with RSVP-TE. These problems may techniques and problems associated with RSVP-TE. These problems may
be exacerbated in P2MP situations where security relationships may be exacerbated in P2MP situations where security relationships may
need to maintained between an ingress and multiple egresses. Such need to maintained between an ingress and multiple egresses. Such
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. IANA Considerations
This informational draft does not introduce any new encodings or code
points. It requires no action from IANA.
7. 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 Thanks to Loa Andersson for his help resolving the final issues in
this document. this document.
7. References 8. References
7.1 Normative References 8.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.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
7.2 Informational References 8.2 Informational References
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003. RFC 3471, January 2003.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
skipping to change at page 26, line 30 skipping to change at page 26, line 30
[RFC3564] F. Le Faucheur, W. Lai, "Requirements for Support of [RFC3564] F. Le Faucheur, W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003. Engineering", RFC 3564, July 2003.
[RFC3630] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering [RFC3630] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
[GMPLS-ROUTE] K. Kompella, Y. Rekhter, Editor, "Routing Extensions [GMPLS-ROUTE] K. Kompella, Y. Rekhter, Editor, "Routing Extensions
in Support of Generalized Multi-Protocol Label in Support of Generalized Multi-Protocol Label
Switching", draft-ietf-ccamp-gmpls-routing-09.txt, Switching", draft-ietf-ccamp-gmpls-routing, work in
October 2003. progress.
[STEINER] H. Salama, et al., "Evaluation of Multicast Routing [STEINER] H. Salama, et al., "Evaluation of Multicast Routing
Algorithm for Real-Time Communication on High-Speed Algorithm for Real-Time Communication on High-Speed
Networks," IEEE Journal on Selected Area in Networks," IEEE Journal on Selected Area in
Communications, pp.332-345, 1997. Communications, pp.332-345, 1997.
[FRR] P. Pan, G. Swallow, A. Atlas, "Fast Reroute Extensions [FRR] P. Pan, G. Swallow, A. Atlas, "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels", to RSVP-TE for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress.
August 2004.
[IS-IS-TE] Henk Smit, Tony Li, "Intermediate System to [IS-IS-TE] Henk Smit, Tony Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004. Engineering (TE)", RFC 3784, June 2004.
[CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G. [CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G.
Ash, S. Marshall, "Crankback Signaling Extensions for Ash, S. Marshall, "Crankback Signaling Extensions for
MPLS Signaling", draft-ietf-ccamp-crankback-03.txt, MPLS Signaling", draft-ietf-ccamp-crankback, work in
July 2004. progress.
[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", Generalized MPLS TE",
draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002. draft-ietf-mpls-lsp-hierarchy, work in progress.
8. Editor's Address 9. Editor's Address
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585, Musashino-Shi, Tokyo 180-8585,
Japan Japan
Phone: +81 422 59 4769 Phone: +81 422 59 4769
Email: yasukawa.seisho@lab.ntt.co.jp Email: yasukawa.seisho@lab.ntt.co.jp
9. Authors' Addresses 10. Authors' Addresses
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellensplein 1, Francis Wellensplein 1,
B-2018 Antwerpen, B-2018 Antwerpen,
Belgium Belgium
Phone : +32 3 240 8491 Phone : +32 3 240 8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
JP Vasseur JP Vasseur
skipping to change at page 28, line 35 skipping to change at page 28, line 35
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
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
10. Intellectual Property Consideration 11. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at page 29, line 11 skipping to change at page 29, line 11
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
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 12. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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,
 End of changes. 

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