Internet DRAFT - draft-zheng-mpls-p2mp-topology-agent-reqs
draft-zheng-mpls-p2mp-topology-agent-reqs
MPLS Working Group Hewen Zheng
Internet Draft Jixiong Dong
Huawei
Expires: December 2006 June 15, 2006
MPLS P2MP Topology Agent Requirements
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document presents a set of requirements for leaf nodes and root
node of any point-to-multipoint (P2MP) and multipoint-to-multipoint
(MP2MP) Label Switched Paths (LSP) know each other dynamically
without requiring a multicast routing protocol in connection-oriented
service provider core networks, especially in Multi-Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
Zheng Expires October 15, 2006 [Page 1]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction.................................................2
2. Requirements.................................................3
2.1. Learning Multicast Membership...........................3
2.2. Updating Multicast Membership...........................4
2.3. Distributing Multicast Membership.......................4
2.4. Redundant...............................................5
2.5. Applicable..............................................5
3. Investigations...............................................5
4. Security Considerations......................................6
5. IANA Considerations..........................................6
6. Acknowledgments..............................................6
7. References...................................................6
7.1. Normative References....................................6
7.2. Informative References..................................7
8. Author's Addresses...........................................8
9. Intellectual Property Statement..............................8
Disclaimer of Validity..........................................8
Copyright Statement.............................................9
Acknowledgment..................................................9
1. Introduction
MPLS is applied widely in service provider core network; those
applications are based point-to-point (P2P) LSP. Recently P2MP and
MP2MP applications are considered. Those applications are based on
P2MP and MP2MP LSP. The document [2] provides one mechanism to
establish P2MP and MP2MP LSP using extended Label Distribution
Protocol (LDP) in MPLS networks; another document [3] provides one
mechanism to set up P2MP LSP using extended Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) in MPLS and GMPLS networks.
The signaling solution for the construction of P2MP MPLS-TE LSPs [3]
assumes that the ingress node for any P2MP LSP knows the identities
of all of the receivers. No mechanism is provided by which it can
discover the identities of those receivers.
Zheng Expires December 15, 2006 [Page 2]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
In multicast LDP (mLDP) [2] it is assumed that each receiver knows
the identity of the source of the distribution tree, but no mechanism
is provided whereby the receivers can discover that information.
In order to successfully operate P2MP MPLS, and to consider extending
MPLS to support MP2MP it is necessary to examine the requirements for
exchanging and learning the identities of P2MP roots and leaves. This
document lists those requirements with an emphasis on dynamic
discovery. The objective is to provide the foundations for an
available and scalable solution that is applicable in MPLS and GMPLS
environments, utilizes existing protocols where possible, and does
not require the introduction of additional protocols into existing
MPLS or GMPLS networks.
2. Requirements
In this section, those requirements are described in detail. This
document assumes one element can satisfy those requirements, this one
element is called multicast membership agent (MMA), and it is only
one concept. MTA should be responsible to learn and distribute
multicast membership information dynamically to provide multicast
topology information for P2MP LSPs establishment without requiring a
multicast routing protocol.
2.1. Learning Multicast Membership
MMA should directly learn multicast membership from any node in MPLS
network if one of the following conditions holds:
(a) One multicast packet first arrives at any ingress node, or
(b) One multicast service is enabled statically at any node, or
(c) One multicast service request is initiated from any egress node.
The multicast service means one combination including multicast
source and multicast group.
MMA has one multicast membership database consisting of many
multicast membership entries. Any membership entry should including
multicast service information, P2MP roots which provide the multicast
service and maybe P2MP leaves which request the multicast service.
Certainly MMA can learn the membership information from any other MMA
in other MPLS domain or one backup MMA in the same domain, the
process also is called synchronization or redundancy.
Zheng Expires December 15, 2006 [Page 3]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
2.2. Updating Multicast Membership
According to the document [1], the multicast topology in MPLS
environment is dynamical; hence MMA must learn multicast membership
dynamically basing on the real-time multicast topology. It means MMA
must update its multicast membership database containing multicast
membership entries initiatively and passively to reflect real
multicast topology. That is to say, any multicast membership entry
has its lifetime. The lifetime may be permanent or finite. The
lifetime for any entry should be configurable to adapt various needs
in real deployment.
Once one entry is aged out in MMA, MMA should query toward the node
that releases the multicast membership information about whether the
entry is still active in the node. The update is initiative for MMA.
Once one entry is aged out in one node that releases multicast
membership information to MMA, it should let MMA know the multicast
membership becomes unavailable. The same action should happen for any
node once the network administrator clears one static multicast
membership setting on it.
2.3. Distributing Multicast Membership
MMA supports to distribute interesting multicast membership to any
node in MPLS network initiatively or passively. Any leaf can learn
the location of root for one specified multicast service from MMA and
then initiate one P2MP LSP using existing mechanism defined in
document [2] or [3]. At the same time, the root can know the
information from MMA about where those interested leaves are. For
P2MP LSP, the root means the ingress node; the leaf means one egress
node.
MMA can be implemented centralized or distributed. The location of
MMA may be released automatically and dynamically to any node in MPLS
network, this information maybe be statically configured. The
following description in this section focuses on centralized mode.
In passive mode, any node can query the specified multicast
membership information from known MMA if it cannot find it in its
local cache. MMA should complete looking up in its database for any
query requirement from one node and let the node know the result. MMA
should support looking up basing some polices. MMA may inherit those
polices during learning those mappings or directly obtain those
polices from policy server such as common open policy server (COPS).
Those policies may include the constraints on access range, QoS
parameters, bandwidth parameters etc.
Zheng Expires December 15, 2006 [Page 4]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
2.4. Redundant
MMA may support redundant in the same domain or many different
domains. The multicast membership can be synchronized from one MMA to
another after being permitted.
In one domain, only one active MMA should be released and used to
learn, update and distribute multicast membership information.
Multicast membership information should be synchronized between the
active MMA and one or more standby MMAs.
Due to the access limitation for nodes among different MPLS domain,
each domain has its active MMA. MMA on the border of one domain may
be release to another domain, or the multicast membership database is
synchronized to another MMA in another domain, then it becomes
possible for P2MP and MP2MP across different domains.
2.5. Applicable
The speed of response from MMA directly influences the speed of P2MP
LSP establishment, but it is not the most sensitive for connection-
oriented MPLS network. If the implementation of MMA is in one light
weight manner, it is sufficient.
Any implementation and deployment for MMA should be in a scalable
manner.
Certainly one problem about security attack on MMA arises. Any
ruinous multicast membership release or query for MMA should be
considered carefully in implementation.
3. Investigations
For the aforementioned requirements, there is not any existing
protocol or one combination of some protocols to completely satisfy
those requirements even in IP multicast environment.
PIM-SM [12] does not satisfy clearly those requirements.
MSDP [15] supports multicast membership synchronization, but it does
not support distributing any multicast membership passively or
initiatively and it is based on one multicast routing protocol - PIM-
SM.
Zheng Expires December 15, 2006 [Page 5]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
At the same time, some work is in progress. For L3VPN applications,
it is one choice to carry and distribute multicast membership
information through auto-discovery mechanism based on extended BGP
defined in the document [6]. For P2MP MPLS-TE applications, one
effort is to extend IGP-TE for such purpose using one analogous
mechanism defined in the document [5]. For connection-oriented
transport network basing on MPLS, one mechanism defined in the
document [4] should be referred. Extension to MSDP is another choice
to satisfy those requirements directly if possible.
4. Security Considerations
This requirements document does not define any protocol extensions
and does not make any changes to any security models therefore.
5. IANA Considerations
This document does not raise any IANA consideration issues.
6. Acknowledgments
The author would like to acknowledge the constructive feedback from
Jean-Louis Le Roux, Adrian Farrel, Dimitri Papadimitriou and Ina
Minei.
7. References
7.1. Normative References
[1] D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari,
"Overview of IP Multicast in a Multi-Protocol Label
Switching (MPLS) Environment", RFC3353, August 2002
[2] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label
Distribution Protocol Extensions for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths", draft-
ietf-mpls-ldp-p2mp-00.txt, February 2006
[3] R. Aggarwal, D. Papadimitriou, S. Yasukawa, "Extensions to RSVP-
TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-
te-p2mp-05.txt, May 2006
[4] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC2022, November 1996
Zheng Expires December 15, 2006 [Page 6]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
[5] J.P. Vasseur, J.L. Le Roux, etc., "Routing extensions for
discovery of Traffic Engineering Node Capabilities", draft-
ietf-ccamp-te-node-cap-01.txt, June 2006
[6] R. Aggarwal, C. Kodeboniya, Y. Rekhter, E. Rosen, T. Morin, "BGP
Encodings for Multicast in MPLS/BGP IP VPNs", draft-
raggarwa-l3vpn-2547bis-mcast-bgp-01.txt, March 2006
[7] H. Ould-Brahim, E. Rosen, Y. Rekhter, "Using BGP as an Auto-
Discovery Mechanism for VR-based Layer-3 VPNs", draft-ietf-
l3vpn-bgpvpn-auto-07.txt, April 2006
7.2. Informative References
[8] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC3031, January 2001
[9] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
Assignment and Context Specific Label Space", draft-ietf-
mpls-upstream-label-00.txt, February 2006
[10] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for
LDP", draft-ietf-mpls-ldp-upstream-00.txt, March 2006
[11] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for
RSVP-TE", draft-ietf-mpls-rsvp-upstream-00.txt,March 2006
[12] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC2362, June 1998
[13] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous
Point (RP) mechanism using Protocol Independent Multicast
(PIM) and Multicast Source Discovery Protocol (MSDP)",
RFC3446, January 2003
[14] S. Bhattacharyya, "An Overview of Source-Specific Multicast
(SSM)", RFC3569, July 2003
[15] B. Fenner, D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC3618, October 2003
Zheng Expires December 15, 2006 [Page 7]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
8. Author's Addresses
Hewen Zhang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: hwzheng@huawei.com
Jixiong Dong
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: dongjixiong@huawei.com
9. Intellectual Property Statement
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
Disclaimer of Validity
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.
Zheng Expires December 15, 2006 [Page 8]
draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zheng Expires December 15, 2006 [Page 9]
