churn per day; that is, a relatively slow rate of churn.
We could say that a P2MP LSP would be shared by multiple multicast
groups, so the dynamics of the P2MP LSP would be relatively small.
Solutions MUST optimize for such relatively low rates of change and
are not required to optimize for significantly higher rates of
change.
- Rate of change within the network.
It is also important to understand the scaling with regard to
changes within the network. That is, one of the features of a P2MP
TE LSP is that it can be robust or protected against network
failures, and it can be re-optimized to take advantage of newly
available network resources.
It is more important that a solution be optimized for scaling with
respect to recovery and re-optimization of the LSP than for change
in the egress LSRs, because P2MP is used as a TE tool.
The solution MUST follow this distinction and optimize accordingly.
4.19. Backwards Compatibility
It SHOULD be an aim of any P2MP solution to offer as much backward
compatibility as possible. An ideal that is probably impossible to
achieve would be to offer P2MP services across legacy MPLS networks
without any change to any LSR in the network.
If this ideal cannot be achieved, the aim SHOULD be to use legacy
nodes as both transit non-branch LSRs and egress LSRs.
It is a further requirement for the solution that any LSR that
implements the solution SHALL NOT be prohibited by that act from
supporting P2P TE LSPs using existing signaling mechanisms. That is,
unless doing so is administratively prohibited, P2P TE LSPs MUST be
supported through a P2MP network.
Also, it is a requirement that P2MP TE LSPs MUST be able to coexist
with IP unicast and IP multicast networks.
4.20. GMPLS
The requirement for P2MP services for non-packet switch interfaces is
similar to that for Packet-Switch Capable (PSC) interfaces.
Therefore, it is a requirement that reasonable attempts must be made
to make all the features/mechanisms (and protocol extensions) that
will be defined to provide MPLS P2MP TE LSPs equally applicable to
P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC
networks over-complicate the PSC solution a decision may be taken to
separate the solutions.
Solutions for MPLS P2MP TE-LSPs, when applied to GMPLS P2MP PSC or
non-PSC TE-LSPs, MUST be compatible with the other features of GMPLS
including:
- control and data plane separation;
- full support of numbered and unnumbered TE links;
- use of the arbitrary labels and labels for specific technologies,
as well as negotiation of labels, where necessary, to support
limited label processing and swapping capabilities;
- the ability to apply external control to the labels selected on
each hop of the LSP, and to control the next hop
label/port/interface for data after it reaches the egress LSR;
- support for graceful and alarm-free enablement and termination of
LSPs;
- full support for protection including link-level protection,
end-to-end protection, and segment protection;
- the ability to teardown an LSP from a downstream LSR, in
particular, from the egress LSR;
- handling of Graceful Deletion procedures; and
- support for failure and restart or reconnection of the control
plane without any disruption of the data plane.
In addition, since non-PSC TE-LSPs may have to be processed in
environments where the "P2MP capability" could be limited, specific
constraints may also apply during the P2MP TE Path computation.
Being technology specific, these constraints are outside the scope of
this document. However, technology-independent constraints (i.e.,
constraints that are applicable independently of the LSP class)
SHOULD be allowed during P2MP TE LSP message processing. It has to
be emphasized that path computation and management techniques shall
be as close as possible to those being used for PSC P2P TE LSPs and
P2MP TE LSPs.
4.21. P2MP Crankback Routing
P2MP solutions SHOULD support crankback requirements as defined in
[CRANKBACK]. In particular, they SHOULD provide sufficient
information to a branch LSR from downstream LSRs to allow the branch
LSR to re-route a sub-LSP around any failures or problems in the
network.
5. Security Considerations
This requirements document does not define any protocol extensions
and does not, therefore, make any changes to any security models.
It is a requirement that any P2MP solution developed to meet some or
all of the requirements expressed in this document MUST include
mechanisms to enable the secure establishment and management of P2MP
MPLS-TE LSPs. This includes, but is not limited to:
- mechanisms to ensure that the ingress LSR of a P2MP LSP is
identified;
- mechanisms to ensure that communicating signaling entities can
verify each other’s identities;
- mechanisms to ensure that control plane messages are protected
against spoofing and tampering;
- mechanisms to ensure that unauthorized leaves or branches are not
added to the P2MP LSP; and
- mechanisms to protect signaling messages from snooping.
Note that P2MP signaling mechanisms built on P2P RSVP-TE signaling
are likely to inherit all the security techniques and problems
associated with RSVP-TE. These problems may be exacerbated in P2MP
situations where security relationships may need to maintained
between an ingress LSR and multiple egress LSRs. Such issues are
similar to security issues for IP multicast.
It is a requirement that documents offering solutions for P2MP LSPs
MUST have detailed security sections.
6. Acknowledgements
The authors would like to thank George Swallow, Ichiro Inoue, Dean
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 and to Harald Alvestrand for a thorough GenArt review.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
7.2. Informative References
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS
signaling protocols", RFC 3468, February 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[STEINER] H. Salama, et al., "Evaluation of Multicast Routing
Algorithm for Real-Time Communication on High-Speed
Networks," IEEE Journal on Selected Area in
Communications, pp.332-345, 1997.
[CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G.
Ash, S. Marshall, "Crankback Signaling Extensions for
MPLS Signaling", Work in Progress, May 2005.
[P2MP-OAM] S. Yasukawa, A. Farrel, D. King, and T. Nadeau, "OAM
Requirements for Point-to-Multipoint MPLS Networks",
Work in Progress, February 2006.
Editor’s Address
Seisho Yasukawa
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585,
Japan
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Authors’ Addresses
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen,
Belgium
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
JP Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719,
USA
EMail: jpv@cisco.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku,
Tokyo 163-1421,
Japan
EMail: y.kamite@ntt.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
EMail: rahul@juniper.net
Alan Kullberg
Motorola Computer Group
120 Turnpike Rd.
Southborough, MA 01772
EMail: alan.kullberg@motorola.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Markus Jork
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
EMail: mjork@quarrytech.com
Andrew G. Malis
Tellabs
2730 Orchard Parkway
San Jose, CA 95134
Phone: +1 408 383 7223
EMail: andy.malis@tellabs.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: jeanlouis.leroux@francetelecom.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).