draft-ietf-mpls-mp-ldp-reqs-05.txt   draft-ietf-mpls-mp-ldp-reqs-06.txt 
MPLS J. Le Roux, Ed. MPLS J. Le Roux, Ed.
Internet-Draft T. Morin Internet-Draft T. Morin
Intended status: Informational V. Parfait Intended status: Informational V. Parfait
Expires: May 30, 2011 France Telecom - Orange Expires: June 4, 2011 France Telecom - Orange
L. Fang L. Fang
Cisco Cisco
L. Wang L. Wang
Telenor Telenor
Y. Kamite Y. Kamite
NTT NTT
S. Amante S. Amante
Level3 Level3
November 26, 2010 December 01, 2010
Requirements for Point-To-Multipoint Extensions to the Label Requirements for Point-To-Multipoint Extensions to the Label
Distribution Protocol Distribution Protocol
draft-ietf-mpls-mp-ldp-reqs-05 draft-ietf-mpls-mp-ldp-reqs-06
Abstract Abstract
This document lists a set of functional requirements for Label This document lists a set of functional requirements for Label
Distribution Protocol (LDP) extensions for setting up point-to- Distribution Protocol (LDP) extensions for setting up point-to-
multipoint (P2MP) Label Switched Paths (LSP), in order to deliver multipoint (P2MP) Label Switched Paths (LSP), in order to deliver
point-to-multipoint applications over a Multi Protocol Label point-to-multipoint applications over a Multi Protocol Label
Switching (MPLS) infrastructure. It is intended that solutions that Switching (MPLS) infrastructure. It is intended that solutions that
specify LDP procedures for setting up P2MP LSP satisfy these specify LDP procedures for setting up P2MP LSP satisfy these
requirements. requirements.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on June 4, 2011.
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 May 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. 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.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement and Requirements Overview . . . . . . . . . 6 3. Problem Statement and Requirements Overview . . . . . . . . . 6
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6
3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7 3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7
skipping to change at page 10, line 17 skipping to change at page 10, line 17
In order to scale well with a large number of leaves it is In order to scale well with a large number of leaves it is
RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For
that purpose, leaves will have to be aware of the P2MP LSP that purpose, leaves will have to be aware of the P2MP LSP
identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely
on the applications that will use P2MP LSPs, and are out of the scope on the applications that will use P2MP LSPs, and are out of the scope
of this document. of this document.
The P2MP LDP mechanism MUST allow the dynamic addition and removal of The P2MP LDP mechanism MUST allow the dynamic addition and removal of
leaves to and from a P2MP LSP, without any restriction (provided leaves to and from a P2MP LSP, without any restriction (provided
there is network connectivity). It is RECOMMENDED that these there is network connectivity). It is RECOMMENDED that these
operations be leaf-initiated. These operations MUST not impact the operations be leaf-initiated. These operations MUST NOT impact the
data transfer (packet loss, duplication, delay) towards other leaves. data transfer (packet loss, duplication, delay) towards other leaves.
It is RECOMMENDED that these operations do not cause any additional It is RECOMMENDED that these operations do not cause any additional
processing except on the path from the added/removed Leaf LSR to the processing except on the path from the added/removed Leaf LSR to the
Branch LSR. Branch LSR.
5.5. Label Advertisement 5.5. Label Advertisement
The P2MP LDP mechanism MUST support downstream unsolicited label The P2MP LDP mechanism MUST support downstream unsolicited label
advertisement mode. This is well suited to a leaf-initiated approach advertisement mode. This is well suited to a leaf-initiated approach
and is consistent with P2P/MP2P LDP operations. and is consistent with P2P/MP2P LDP operations.
skipping to change at page 10, line 48 skipping to change at page 10, line 48
Note, in particular, that data duplication might occur if P2MP LSP Note, in particular, that data duplication might occur if P2MP LSP
rerouting is being performed (See also section 6.8). rerouting is being performed (See also section 6.8).
5.7. Detecting and Avoiding Loops 5.7. Detecting and Avoiding Loops
The P2MP LDP extension MUST have a mechanism to detect routing loops. The P2MP LDP extension MUST have a mechanism to detect routing loops.
This may rely on extensions to the LDP Loop detection mechanism This may rely on extensions to the LDP Loop detection mechanism
defined in [RFC5036]. A loop detection mechanism may require defined in [RFC5036]. A loop detection mechanism may require
recording the set of LSRs traversed on the P2MP Tree. The P2MP loop recording the set of LSRs traversed on the P2MP Tree. The P2MP loop
avoidance mechanism MUST not impact the scalability of the P2MP LDP avoidance mechanism MUST NOT impact the scalability of the P2MP LDP
solution. solution.
The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops
in the data plane even during transient events. in the data plane even during transient events.
Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the
data plane, that may trigger unexpected non-localized exponential data plane, that may trigger unexpected non-localized exponential
growth of traffic. growth of traffic.
5.8. P2MP LSP Re-routing 5.8. P2MP LSP Re-routing
skipping to change at page 14, line 21 skipping to change at page 14, line 21
5.18. Backward Compatibility 5.18. Backward Compatibility
In order to allow for a smooth migration, the P2MP LDP mechanism In order to allow for a smooth migration, the P2MP LDP mechanism
SHOULD offer as much backward compatibility as possible. In SHOULD offer as much backward compatibility as possible. In
particular, the solution SHOULD allow the setup of a P2MP LSP along particular, the solution SHOULD allow the setup of a P2MP LSP along
non-Branch Transit LSRs that do not support P2MP LDP extensions. non-Branch Transit LSRs that do not support P2MP LDP extensions.
Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms
and inherit its capability sets from [RFC5036]. The P2MP LDP 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 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 solution MUST be designed in such a way that it allows P2P/MP2P and
P2MP LSPs to be signalled on the same interface. P2MP LSPs to be signalled on the same interface.
6. Shared Trees 6. Shared Trees
For traffic delivery between a group of N Leaf LSRs which are acting For traffic delivery between a group of N Leaf LSRs which are acting
indifferently as Ingress or Egress LSRs, it may be useful to setup a indifferently as Ingress or Egress LSRs, it may be useful to setup a
shared tree connecting all these LSRs, instead of having N P2MP LSPs. shared tree connecting all these LSRs, instead of having N P2MP LSPs.
This would reduce the amount of control and forwarding state that has This would reduce the amount of control and forwarding state that has
to be maintained on a given LSR. to be maintained on a given LSR.
skipping to change at page 15, line 17 skipping to change at page 15, line 17
6.1. Requirements for MP2MP LSPs 6.1. Requirements for MP2MP LSPs
A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting
indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf
LSR is received by all other Leaf LSRs of the group. LSR is received by all other Leaf LSRs of the group.
Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. Procedures for setting up MP2MP LSPs with LDP SHOULD be specified.
An implementation that support P2MP LDP LSPs MAY also support MP2MP An implementation that support P2MP LDP LSPs MAY also support MP2MP
LDP LSP. LDP LSP.
The MP2MP LDP procedures MUST not impede the operations of P2MP LSP. The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.
Requirements for P2MP LSPs, set forth in section 6, apply equally to Requirements for P2MP LSPs, set forth in section 6, apply equally to
MP2MP LSPs. Particular attention should be given on the below MP2MP LSPs. Particular attention should be given on the below
requirements: requirements:
o The solution MUST support recovery upon link and transit node o The solution MUST support recovery upon link and transit node
failure and there MUST NOT be any single point of failure failure and there MUST NOT be any single point of failure
(provided network connectivity is redundant); (provided network connectivity is redundant);
o The size of MP2MP state on a LSR, for one particular MP2MP LSP, o The size of MP2MP state on a LSR, for one particular MP2MP LSP,
skipping to change at page 15, line 43 skipping to change at page 15, line 43
receive traffic for a given LSP on multiple interfaces. receive traffic for a given LSP on multiple interfaces.
There are additional requirements specific to MP2MP LSPs: There are additional requirements specific to MP2MP LSPs:
o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a
specific LSR called root LSR; specific LSR called root LSR;
o It is RECOMMENDED to define several root LSRs (e.g. a primary and o It is RECOMMENDED to define several root LSRs (e.g. a primary and
a backup) to ensure redundancy upon root LSR failure; a backup) to ensure redundancy upon root LSR failure;
o The receiver SHOULD not receive back a packet it has sent on the o The receiver SHOULD NOT receive back a packet it has sent on the
MP2MP LSP; MP2MP LSP;
o The solution SHOULD avoid that all traffic between any pair of o The solution SHOULD avoid that all traffic between any pair of
leaves is traversing a root LSR, and SHOULD as much as possible leaves is traversing a root LSR, and SHOULD as much as possible
minimize the distance between two leaves (similarly to PIM-Bidir minimize the distance between two leaves (similarly to PIM-Bidir
trees); trees);
o It MUST be possible to check connectivity of a MP2MP LSP in both o It MUST be possible to check connectivity of a MP2MP LSP in both
directions. directions.
skipping to change at page 16, line 31 skipping to change at page 16, line 31
Particularly the P2MP LDP mechanism SHOULD be designed with as key Particularly the P2MP LDP mechanism SHOULD be designed with as key
objective to minimize the additional amount of state and additional objective to minimize the additional amount of state and additional
processing required in the network. processing required in the network.
Also, the P2MP LDP mechanism SHOULD be designed so that convergence Also, the P2MP LDP mechanism SHOULD be designed so that convergence
times in case of link or node failure are minimized, in order to times in case of link or node failure are minimized, in order to
limit traffic disruption. limit traffic disruption.
7.2. Complexity and Risks 7.2. Complexity and Risks
The proposed solution SHOULD not introduce complexity to the current The proposed solution SHOULD NOT introduce complexity to the current
LDP operations to such a degree that it would affect the stability LDP operations to such a degree that it would affect the stability
and diminish the benefits of deploying such solution. and diminish the benefits of deploying such solution.
8. Security Considerations 8. Security Considerations
This document does not introduce any new security issue beyond those This document does not introduce any new security issue beyond those
inherent to LDP, and a P2MP LDP solution will rely on the security inherent to LDP, and a P2MP LDP solution will rely on the security
mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature). mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature).
An evaluation of the security features for MPLS networks may be found An evaluation of the security features for MPLS networks may be found
 End of changes. 13 change blocks. 
21 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/