GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6348

Internet Engineering Task Force (IETF) J. Le Roux, Ed. Request for Comments: 6348 T. Morin, Ed. Category: Historic France Telecom - Orange ISSN: 2070-1721 September 2011

          Requirements for Point-to-Multipoint Extensions
                 to the Label Distribution Protocol

Abstract

 This document lists a set of functional requirements that served as
 input to the design of Label Distribution Protocol (LDP) extensions
 for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP),
 in order to deliver point-to-multipoint applications over a
 Multiprotocol Label Switching (MPLS) infrastructure.
 This work was overtaken by the protocol solution developed by the
 MPLS working group, but that solution did not closely follow the
 requirements documented here.  This document is published as a
 historic record of the ideas and requirements that shaped the
 protocol work.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for the historical record.
 This document defines a Historic Document for the Internet community.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6348.

Le Roux & Morin Historic [Page 1] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Le Roux & Morin Historic [Page 2] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   1.2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.  Context and Motivations  . . . . . . . . . . . . . . . . .  6
   1.4.  Document Scope . . . . . . . . . . . . . . . . . . . . . .  7
 2.  Requirements Overview  . . . . . . . . . . . . . . . . . . . .  7
 3.  Application Scenario . . . . . . . . . . . . . . . . . . . . .  8
 4.  Detailed Requirements  . . . . . . . . . . . . . . . . . . . .  9
   4.1.  P2MP LSPs  . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.2.  P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 10
   4.3.  P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10
   4.4.  Setting Up, Tearing Down, and Modifying P2MP LSPs  . . . . 10
   4.5.  Label Advertisement  . . . . . . . . . . . . . . . . . . . 10
   4.6.  Data Duplication . . . . . . . . . . . . . . . . . . . . . 11
   4.7.  Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11
   4.8.  P2MP LSP Rerouting . . . . . . . . . . . . . . . . . . . . 11
   4.9.  Support for Multi-Access Networks  . . . . . . . . . . . . 12
   4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12
   4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13
   4.12. IPv4/IPv6 Support  . . . . . . . . . . . . . . . . . . . . 13
   4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13
   4.14. OAM  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.15. Graceful Restart and Fault Recovery  . . . . . . . . . . . 14
   4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.17. Scalability  . . . . . . . . . . . . . . . . . . . . . . . 14
   4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14
 5.  Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.1.  Requirements for MP2MP LSPs  . . . . . . . . . . . . . . . 15
 6.  Evaluation Criteria  . . . . . . . . . . . . . . . . . . . . . 16
   6.1.  Performance  . . . . . . . . . . . . . . . . . . . . . . . 16
   6.2.  Complexity and Risks . . . . . . . . . . . . . . . . . . . 17
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
 8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
 Contributing Authors . . . . . . . . . . . . . . . . . . . . . . . 20

Le Roux & Morin Historic [Page 3] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

1. Introduction

 This document lists a set of functional requirements that served as
 input to the design of Label Distribution Protocol (LDP) extensions
 for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP)
 [MLDP], in order to deliver point-to-multipoint applications over a
 Multiprotocol Label Switching (MPLS) infrastructure.
 This work was overtaken by the protocol solution developed by the
 MPLS working group and documented in [MLDP].  That solution did not
 closely follow the requirements documented here, and it was
 recognized that this document had served its purpose in driving
 discussions of how the solution should be designed.  At this point,
 no further action is planned to update this document in line with the
 protocol solution, and this document is published simply as a
 historic record of the ideas and requirements that shaped the
 protocol work.
 The document is structured as follows:
 o  Section 2 is an overview of the requirements.
 o  Section 3 illustrates an application scenario.
 o  Section 4 addresses detailed requirements for P2MP LSPs.
 o  Section 5 discusses requirements for shared trees and multipoint-
    to-multipoint (MP2MP) LSPs.
 o  Section 6 presents criteria against which a solution can be
    evaluated.

1.1. Requirements Language

 This document is a historic requirements document.  To clarify
 statement of requirements, key words are used as follows.  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 [RFC2119].

1.2. Definitions

1.2.1. Acronyms

 P2P:  Point-to-Point
 MP2P:  Multipoint-to-Point

Le Roux & Morin Historic [Page 4] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 P2MP:  Point-to-Multipoint
 MP2MP:  Multipoint-to-Multipoint
 LSP:  Label Switched Path
 LSR:  Label Switching Router
 PE:  Provider Edge
 P: Provider
 IGP:  Interior Gateway Protocol
 AS:  Autonomous System

1.2.2. Terminology

 The reader is assumed to be familiar with the terminology in
 [RFC3031], [RFC5036], and [RFC4026].
 Ingress LSR:
    Router acting as a sender of an LSP
 Egress LSR:
    Router acting as a receiver of an LSP
 P2P LSP:
    An LSP that has one unique Ingress LSR and one unique Egress LSR
 MP2P LSP:
    An LSP that has one or more Ingress LSRs and one unique Egress LSR
 P2MP LSP:
    An LSP that has one unique Ingress LSR and one or more Egress LSRs
 MP2MP LSP:
    An LSP that has one or more Leaf LSRs acting indifferently as
    Ingress or Egress LSR
 Leaf LSR:
    An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of an MP2MP
    LSP
 Transit LSR:
    An LSR of a P2MP or MP2MP LSP that has one or more downstream LSRs

Le Roux & Morin Historic [Page 5] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 Branch LSR:
    An LSR of a P2MP or MP2MP LSP that has more than one downstream
    LSR
 Bud LSR:
    An LSR of a P2MP or MP2MP LSP that is an Egress but also has one
    or more directly connected downstream LSR(s)
 P2MP tree:
    The ordered set of LSRs and links that comprise the path of a P2MP
    LSP from its Ingress LSR to all of its Egress LSRs.

1.3. Context and Motivations

 LDP [RFC5036] has been deployed for setting up point-to-point (P2P)
 and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point
 services in MPLS backbones.
 There are emerging requirements for supporting delivery of point-to-
 multipoint applications in MPLS backbones, such as those defined in
 [RFC4834] and [RFC5501].
 For various reasons, including consistency with P2P applications, and
 taking full advantages of MPLS network infrastructure, it would be
 highly desirable to use MPLS LSPs for the delivery of multicast
 traffic.  This could be implemented by setting up a group of P2P or
 MP2P LSPs, but such an approach may be inefficient since it would
 result in data replication at the Ingress LSR and duplicate data
 traffic within the network.
 Hence, new mechanisms are required that would allow traffic from an
 Ingress LSR to be efficiently delivered to a number of Egress LSRs in
 an MPLS backbone on a point-to-multipoint LSP (P2MP LSP), avoiding
 duplicate copies of a packet on a given link and relying on MPLS
 traffic replication at some Branch LSRs.
 Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
 extensions for setting up point-to-multipoint Traffic Engineered LSPs
 (P2MP TE LSPs) have been defined in [RFC4875].  They meet
 requirements expressed in [RFC4461].  This approach is useful in
 network environments where P2MP Traffic Engineering capabilities are
 needed (optimization, QoS, fast recovery).
 However, for operators who want to support point-to-multipoint
 traffic delivery on an MPLS backbone, without Traffic Engineering
 needs, and who have already deployed LDP for P2P traffic, an
 interesting and useful approach would be to rely on LDP extensions in
 order to set up point-to-multipoint (P2MP) LSPs.  This would bring

Le Roux & Morin Historic [Page 6] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 consistency with P2P MPLS applications and would ease the delivery of
 point-to-multipoint services in an MPLS backbone.

1.4. Document Scope

 This document focuses on the LDP approach for setting up P2MP LSPs.
 It lists a detailed set of requirements for P2MP extensions to LDP,
 so as to deliver P2MP traffic over an LDP-enabled MPLS
 infrastructure.  The original intent was that these requirements
 should be used as guidelines when specifying LDP extensions.
 Note that generic requirements for P2MP extensions to MPLS are out of
 the scope of this document.  Rather, this document describes
 solution-specific requirements related to LDP extensions in order to
 set up P2MP LSPs.
 Note also that other mechanisms could be used for setting up P2MP
 LSPs (for instance, PIM extensions), but these are out of the scope
 of this document.  The objective is not to compare these mechanisms
 but rather to focus on the requirements for an LDP extension
 approach.

2. Requirements Overview

 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e., LSPs
 with one Ingress LSR and one or more Egress LSRs, with traffic
 replication at some Branch LSRs.
 The P2MP LDP mechanism MUST allow the addition or removal of leaves
 associated with a P2MP LSP.
 The P2MP LDP mechanism MUST coexist with current LDP mechanisms and
 inherit its capability sets from [RFC5036].  It is of paramount
 importance that the P2MP LDP mechanism MUST NOT impede the operation
 of existing P2P/MP2P LDP LSPs.  Also, the P2MP LDP mechanism MUST
 coexist with P2P and P2MP RSVP-TE mechanisms [RFC3209] [RFC4875].  It
 is of paramount importance that the P2MP LDP mechanism MUST NOT
 impede the operation of existing P2P and P2MP RSVP-TE LSPs.
 The P2MP LDP mechanism MAY also allow setting up multipoint-to-
 multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting
 indifferently as Ingress LSR or Egress LSR.  This may allow a
 reduction in the amount of LDP state that needs to be maintained by
 an LSR.

Le Roux & Morin Historic [Page 7] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

3. Application Scenario

 Figure 1 below illustrates an LDP-enabled MPLS provider network, used
 to carry both unicast and multicast traffic of VPN customers
 following, for instance, the architecture defined in [MVPN] for BGP/
 MPLS VPNs or the one defined in [VPLS-MCAST].
 In this example, a set of MP2P LDP LSPs is set up between Provider
 Edge (PE) routers to carry unicast VPN traffic within the MPLS
 backbone (not represented in Figure 1).
 In this example, a set of P2MP LDP LSPs is set up between PE routers
 acting as Ingress LSRs and PE routers acting as Egress LSRs, so as to
 support multicast VPN traffic delivery within the MPLS backbone.
 For instance, a P2MP LDP LSP is set up between Ingress LSR PE1 and
 Egress LSRs PE2, PE3, and PE4.  It is used to transport multicast
 traffic from PE1 to PE2, PE3, and PE4.  P1 is a Branch LSR; it
 replicates MPLS traffic sent by PE1 to P2, P3, and PE2.  P2 and P3
 are non-Branch Transit LSRs; they forward MPLS traffic sent by P1 to
 PE3 and PE4, respectively.
                        PE1
                        *|                *** P2MP LDP LSP
                        *|*****
                        P1-----PE2
                       */ \*
                      */   \*
                 *****/     \******
              PE3----P2      P3----PE4
                     |       |
                     |       |
                     |       |
                    PE5     PE6
             Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4

Le Roux & Morin Historic [Page 8] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 If later there are new receivers attached to PE5 and PE6, then PE5
 and PE6 join the P2MP LDP LSP.  P2 and P3 become Branch LSRs and
 replicate traffic received from P1 to PE3 and PE5 and to PE4 and PE6,
 respectively (see Figure 2 below).
                        PE1
                        *|               *** P2MP LDP LSP
                        *|*****
                        P1-----PE2
                       */ \*
                      */   \*
                 *****/     \******
              PE3----P2      P3----PE4
                    *|       |*
                    *|       |*
                    *|       |*
                    PE5     PE6
                  Figure 2: Attachment of PE5 and PE6
 The above example is provided for the sake of illustration.  Note
 that P2MP LSPs Ingress and Egress LSRs may not necessarily be PE
 routers.  Also, Branch LSRs may not necessarily be P routers.

4. Detailed Requirements

4.1. P2MP LSPs

 The P2MP LDP mechanism MUST support setting up P2MP LSPs.  Data plane
 aspects related to P2MP LSPs are those already defined in [RFC4461].
 That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs.
 Traffic sent by the Ingress LSR is received by all Egress LSRs.  The
 specific aspect related to P2MP LSPs is the action required at a
 Branch LSR, where data replication occurs.  Incoming labeled data is
 appropriately replicated to several outgoing interfaces, which may
 use different labels.
 An LSR SHOULD NOT send more than one copy of a packet on any given
 link of a P2MP LSP.  Exceptions to this are mentioned in Sections 4.9
 and 4.18.
 A P2MP LSP MUST be identified by a constant and unique identifier
 within the whole LDP domain, whatever the number of leaves, which may
 vary dynamically.  This identifier will be used so as to add/remove
 leaves to/from the P2MP tree.

Le Roux & Morin Historic [Page 9] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

4.2. P2MP LSP FEC

 As with P2P MPLS technology [RFC5036], traffic MUST be classified
 into a Forwarding Equivalence Class (FEC) in this P2MP extension.
 All packets that belong to a particular P2MP FEC and that travel from
 a particular node MUST use the same P2MP LSP.
 If existing FECs cannot be used for this purpose, a new LDP FEC that
 is suitable for P2MP forwarding MUST be specified.

4.3. P2MP LDP Routing

 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support
 hop-by-hop LSP routing.  P2MP LDP-based routing SHOULD rely upon the
 information maintained in LSR Routing Information Bases (RIBs).
 It is RECOMMENDED that the P2MP LSP routing rely upon the unicast
 route to the Ingress LSR to build a reverse path tree.

4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs

 The P2MP LDP mechanism MUST support the establishment, maintenance,
 and teardown of P2MP LSPs in a scalable manner.  This MUST include
 both the existence of a large number of P2MP LSPs within a single
 network and a large number of Leaf LSRs for a single P2MP LSP (see
 also Section 4.17 for scalability considerations and figures).
 In order to scale well with a large number of leaves, it is
 RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach.  For
 that purpose, leaves will have to be aware of the P2MP LSP
 identifier.  The ways a Leaf LSR discovers P2MP LSP identifiers rely
 on the applications that will use P2MP LSPs and are out of the scope
 of this document.
 The P2MP LDP mechanism MUST allow the dynamic addition and removal of
 leaves to and from a P2MP LSP, without any restriction (provided
 there is network connectivity).  It is RECOMMENDED that these
 operations be leaf-initiated.  These operations MUST NOT impact the
 data transfer (packet loss, duplication, delay) towards other leaves.
 It is RECOMMENDED that these operations do not cause any additional
 processing except on the path from the added/removed Leaf LSR to the
 Branch LSR.

4.5. Label Advertisement

 The P2MP LDP mechanism MUST support downstream unsolicited label
 advertisement mode.  This is well suited to a leaf-initiated approach
 and is consistent with P2P/MP2P LDP operations.

Le Roux & Morin Historic [Page 10] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 Other advertisement modes MAY also be supported.

4.6. Data Duplication

 Data duplication refers to the receipt of multiple copies of a packet
 by any leaf.  Although this may be a marginal situation, it may also
 be detrimental for certain applications.  Hence, data duplication
 SHOULD be avoided as much as possible and limited to (hopefully rare)
 transitory conditions.
 Note, in particular, that data duplication might occur if P2MP LSP
 rerouting is being performed (see also Section 4.8).

4.7. Detecting and Avoiding Loops

 The P2MP LDP extension MUST have a mechanism to detect routing loops.
 This MAY rely on extensions to the LDP loop detection mechanism
 defined in [RFC5036].  A loop detection mechanism MAY require
 recording the set of LSRs traversed on the P2MP tree.  The P2MP loop
 avoidance mechanism MUST NOT impact the scalability of the P2MP LDP
 solution.
 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops
 in the data plane even during transient events.
 Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the
 data plane, which may trigger unexpected non-localized exponential
 growth of traffic.

4.8. P2MP LSP Rerouting

 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in
 the following cases:
 o  Network failure (link or node);
 o  A better path exists (e.g., new link or metric change); and
 o  Planned maintenance.
 Given that P2MP LDP routing should rely on the RIB, the achievement
 of the following requirements relies on the underlying routing
 protocols (IGP, etc.).

Le Roux & Morin Historic [Page 11] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

4.8.1. Rerouting upon Network Failure

 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case
 of link or node failure(s) by relying upon update of the routes in
 the RIB.  The rerouting time SHOULD be minimized as much as possible
 so as to reduce traffic disruption.
 A mechanism MUST be defined to prevent constant P2MP LSP teardown and
 rebuild, which may be caused by the instability of a specific link/
 node in the network.  This can rely on IGP dampening but may be
 completed by specific dampening at the LDP level.

4.8.2. Rerouting on a Better Path

 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case
 a better path is created in the network, for instance, as a result of
 a metric change, a link repair, or the addition of links or nodes.
 This will rely on update of the routes in the RIB.

4.8.3. Rerouting upon Planned Maintenance

 The P2MP LDP mechanism MUST support planned maintenance operations.
 It MUST be possible to reroute a P2MP LSP before a link/node is
 deactivated for maintenance purposes.  Traffic disruption and data
 duplication SHOULD be minimized as much as possible during such
 planned maintenance.  P2MP LSP rerouting upon planned maintenance MAY
 rely on a make-before-break procedure.

4.9. Support for Multi-Access Networks

 The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send
 a single copy of the data onto an interface to a multi-access network
 (e.g., an Ethernet LAN) and reach multiple adjacent downstream nodes.
 This requires that the same label be negotiated with all downstream
 LSRs for the LSP.
 When there are several candidate upstream LSRs on an interface to a
 multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all
 downstream LSRs of a given P2MP LSP to select the same upstream LSR,
 so as to avoid traffic replication.  In addition, the P2MP LDP
 mechanism SHOULD allow for an efficient balancing of a set of P2MP
 LSPs among a set of candidate upstream LSRs on a LAN interface.

4.10. Support for Encapsulation in P2P and P2MP TE Tunnels

 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and
 P2MP TE tunnels.

Le Roux & Morin Historic [Page 12] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP
 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a
 single copy of the data onto the tunnel and reach all downstream LSRs
 on the P2MP LSP, which are also Egress LSRs of the tunnel.  As with
 LAN interfaces, this requires that the same label be negotiated with
 all downstream LSRs of the P2MP LDP LSP.

4.11. Label Spaces

 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or
 dedicated label spaces.
 Note that dedicated label spaces will require the establishment of
 separate P2P and P2MP LDP sessions.

4.12. IPv4/IPv6 Support

 The P2MP LDP mechanism MUST support the establishment of LDP sessions
 over both IPv4 and IPv6 control planes.

4.13. Multi-Area/AS LSPs

 The P2MP LDP mechanism MUST support the establishment of multi-area
 P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same IGP
 area as the Ingress LSR.  This SHOULD be possible without requiring
 the advertisement of Ingress LSRs' addresses across IGP areas.
 The P2MP LDP mechanism MUST also support the establishment of
 inter-AS P2MP LSPs, i.e., LSPs whose leaves do not all reside in the
 same AS as the Ingress LSR.  This SHOULD be possible without
 requiring the advertisement of Ingress LSRs' addresses across ASes.

4.14. OAM

 LDP management tools ([RFC3815], etc.) will have to be enhanced to
 support P2MP LDP extensions.  This may yield a new MIB module, which
 may possibly be inherited from the LDP MIB.
 Built-in diagnostic tools MUST be defined to check the connectivity,
 trace the path, and ensure fast detection of data plane failures on
 P2MP LDP LSPs.
 Further and precise requirements and mechanisms for P2MP MPLS
 Operations, Administration, and Maintenance (OAM) purposes are out of
 the scope of this document and are addressed in [RFC4687].

Le Roux & Morin Historic [Page 13] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

4.15. Graceful Restart and Fault Recovery

 LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery
 mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs.

4.16. Robustness

 A solution MUST be designed to re-establish connectivity for P2MP and
 MP2MP LSPs in the event of failures, provided there exists network
 connectivity between ingress and egress nodes (i.e., designed without
 introducing single points of failure).

4.17. Scalability

 Scalability is a key requirement for the P2MP LDP mechanism.  It MUST
 be designed to scale well with an increase in the number of any of
 the following:
 o  Number of Leaf LSRs per P2MP LSP;
 o  Number of downstream LSRs per Branch LSR; and
 o  Number of P2MP LSPs per LSR.
 In order to scale well with an increase in the number of leaves, it
 is RECOMMENDED that the size of a P2MP LSP state on an LSR, for one
 particular LSP, depend only on the number of adjacent LSRs on the
 LSP.

4.17.1. Orders of Magnitude Expected in Operational Networks

 Typical orders of magnitude that we expect should be supported are:
 o  Tens of thousands of P2MP trees spread out across core network
    routers; and
 o  Hundreds, or a few thousands, of leaves per tree.
 See also Section 4.2 of [RFC4834].

4.18. Backward Compatibility

 In order to allow for a smooth migration, the P2MP LDP mechanism
 SHOULD offer as much backward compatibility as possible.  In
 particular, the solution SHOULD allow the setup of a P2MP LSP along
 non-Branch Transit LSRs that do not support P2MP LDP extensions.

Le Roux & Morin Historic [Page 14] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 Also, the P2MP LDP solution MUST coexist with current LDP mechanisms
 and inherit its capability sets from [RFC5036].  The P2MP LDP
 solution MUST NOT impede the operation of P2P/MP2P LSPs.  A P2MP LDP
 solution MUST be designed in such a way that it allows P2P/MP2P and
 P2MP LSPs to be signaled on the same interface.

5. Shared Trees

 For traffic delivery between a group of N LSRs that act as egress
 and/or egress nodes on different P2MP flows, it may be useful to set
 up a shared tree connecting all these LSRs instead of having N P2MP
 LSPs.  This would reduce the amount of control and forwarding state
 that has to be maintained on a given LSR.
 There are two main options for supporting such shared trees:
 o  Relying on the applications' protocols that use LDP LSPs.  A
    shared tree could consist of the combination of an MP2P LDP LSP
    from Leaf LSRs to a given root node with a P2MP LSP from this root
    to Leaf LSRs.  For instance, with Multicast L3 VPN applications,
    it would be possible to build a shared tree by combining (see
    [MVPN]):
  • An MP2P unicast LDP LSP, from each PE router of the group to a

particular root PE router acting as tree root and

  • A P2MP LDP LSP from this root PE router to each PE router of

the group.

 o  Relying on a specific LDP mechanism allowing the setup of
    multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).
 The former approach (combination of MP2P and P2MP LSPs at the
 application level) is out of the scope of this document while the
 latter (MP2MP LSPs) is within the scope of this document.
 Requirements for the setup of MP2MP LSPs are listed below.

5.1. Requirements for MP2MP LSPs

 A multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group
 of Leaf LSRs acting as Egress and/or Ingress LSRs.  Traffic sent by
 any Leaf LSR is received by all other Leaf LSRs of the group.
 Procedures for setting up MP2MP LSPs with LDP SHOULD be specified.
 An implementation that supports P2MP LDP LSPs MAY also support MP2MP
 LDP LSPs.
 The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.

Le Roux & Morin Historic [Page 15] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 Requirements for P2MP LSPs, set forth in Section 4, apply equally to
 MP2MP LSPs.  Particular attention should be given to the requirements
 below:
 o  The solution MUST support recovery upon link and transit node
    failure and be designed to re-establish connectivity for MP2MP
    LSPs in the event of failures, provided network connectivity
    exists between ingress and egress nodes (i.e., designed without
    introducing single points of failure).
 o  The size of MP2MP state on an LSR, for one particular MP2MP LSP,
    SHOULD only depend on the number of adjacent LSRs on the LSP.
 o  Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that
    may trigger exponential growth of traffic.  Note that this
    requirement is more challenging with MP2MP LSPs as an LSR may need
    to receive traffic for a given LSP on multiple interfaces.
 There are additional requirements specific to MP2MP LSPs:
 o  It is RECOMMENDED that an MP2MP MPLS LSP is built based on the
    unicast route to a specific LSR called root LSR.
 o  It is RECOMMENDED to define several root LSRs (e.g., a primary and
    a backup) to ensure redundancy upon root LSR failure.
 o  The receiver SHOULD NOT receive back a packet it has sent on the
    MP2MP LSP.
 o  The solution SHOULD avoid that all traffic between any pair of
    leaves is traversing a root LSR (similarly to PIM-Bidir trees) and
    SHOULD provide the operator with means to minimize the delay
    between two leaves.
 o  It MUST be possible to check connectivity of an MP2MP LSP in both
    directions.

6. Evaluation Criteria

6.1. Performance

 The solution will be evaluated with respect to the following
 criteria:
 (1)  Efficiency of network resource usage;
 (2)  Time to add or remove a Leaf LSR;

Le Roux & Morin Historic [Page 16] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 (3)  Time to repair a P2MP LSP in case of link or node failure; and
 (4)  Scalability (state size, number of messages, message size).
 Particularly, the P2MP LDP mechanism SHOULD be designed with the key
 objective of minimizing the additional amount of state and additional
 processing required in the network.
 Also, the P2MP LDP mechanism SHOULD be designed so that convergence
 times in case of link or node failure are minimized, in order to
 limit traffic disruption.

6.2. Complexity and Risks

 The proposed solution SHOULD NOT introduce complexity to the current
 LDP operations to such a degree that it would affect the stability
 and diminish the benefits of deploying such solution.

7. Security Considerations

 It is expected that addressing the requirements defined in this
 document should not introduce any new security issues beyond those
 inherent to LDP and that a P2MP LDP solution will rely on the
 security mechanisms defined in [RFC5036] (e.g., TCP MD5 Signature).
 An evaluation of the security features for MPLS networks may be found
 in [RFC5920], and where issues or further work is identified by that
 document, new security features or procedures for the MPLS protocols
 will need to be developed.

8. Acknowledgments

 We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina
 Minei, Dean Cheng, and Benjamin Niven-Jenkins for their highly useful
 comments and suggestions.  We would like to thank Adrian Farrel for
 reviewing this document before publication.
 We would also like to thank the authors of [RFC4461], which inspired
 some of the text in this document.

Le Roux & Morin Historic [Page 17] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

9. References

9.1. Normative References

 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC 3031,
               January 2001.
 [RFC3478]     Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
               Restart Mechanism for Label Distribution Protocol",
               RFC 3478, February 2003.
 [RFC3479]     Farrel, A., "Fault Tolerance for the Label Distribution
               Protocol (LDP)", RFC 3479, February 2003.
 [RFC3815]     Cucchiara, J., Sjostrand, H., and J. Luciani,
               "Definitions of Managed Objects for the Multiprotocol
               Label Switching (MPLS), Label Distribution Protocol
               (LDP)", RFC 3815, June 2004.
 [RFC4461]     Yasukawa, S., "Signaling Requirements for Point-to-
               Multipoint Traffic-Engineered MPLS Label Switched Paths
               (LSPs)", RFC 4461, April 2006.
 [RFC5036]     Andersson, L., Minei, I., and B. Thomas, "LDP
               Specification", RFC 5036, October 2007.

9.2. Informative References

 [MLDP]        Minei, I., Wijnands, I., Kompella, K., and B. Thomas,
               "Label Distribution Protocol Extensions for Point-to-
               Multipoint and Multipoint-to-Multipoint Label Switched
               Paths", Work in Progress, August 2011.
 [MVPN]        Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter,
               Y., Rosen, E., Wijnands, I., and S. Yasukawa,
               "Multicast in MPLS/BGP IP VPNs", Work in Progress,
               January 2010.
 [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.

Le Roux & Morin Historic [Page 18] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

 [RFC4026]     Andersson, L. and T. Madsen, "Provider Provisioned
               Virtual Private Network (VPN) Terminology", RFC 4026,
               March 2005.
 [RFC4687]     Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
               "Operations and Management (OAM) Requirements for
               Point-to-Multipoint MPLS Networks", RFC 4687,
               September 2006.
 [RFC4834]     Morin, T., Ed., "Requirements for Multicast in Layer 3
               Provider-Provisioned Virtual Private Networks
               (PPVPNs)", RFC 4834, April 2007.
 [RFC4875]     Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
               "Extensions to Resource Reservation Protocol - Traffic
               Engineering (RSVP-TE) for Point-to-Multipoint TE Label
               Switched Paths (LSPs)", RFC 4875, May 2007.
 [RFC5501]     Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L.
               Fang, "Requirements for Multicast Support in Virtual
               Private LAN Services", RFC 5501, March 2009.
 [RFC5920]     Fang, L., "Security Framework for MPLS and GMPLS
               Networks", RFC 5920, July 2010.
 [VPLS-MCAST]  Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
               "Multicast in VPLS", Work in Progress, July 2011.

Le Roux & Morin Historic [Page 19] RFC 6348 Reqs for P2MP Extensions to LDP September 2011

Contributing Authors

 Vincent Parfait
 France Telecom - Orange, Orange Business Services
 EMail: vincent.parfait@orange-ftgroup.com
 Luyuan Fang
 Cisco Systems, Inc.
 EMail: lufang@cisco.com
 Lei Wang
 Telenor
 EMail: lei.wang@telenor.com
 Yuji Kamite
 NTT Communications Corporation
 EMail: y.kamite@ntt.com
 Shane Amante
 Level 3 Communications, LLC
 EMail: shane@level3.net

Authors' Addresses

 Jean-Louis Le Roux (editor)
 France Telecom - Orange
 EMail: jeanlouis.leroux@orange-ftgroup.com
 Thomas Morin (editor)
 France Telecom - Orange
 EMail: thomas.morin@orange-ftgroup.com

Le Roux & Morin Historic [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6348.txt · Last modified: 2011/09/07 21:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki