One document matched: draft-raggarwa-mpls-p2mp-te-01.txt
Differences from draft-raggarwa-mpls-p2mp-te-00.txt
Network Working Group Rahul Aggarwal (Editor)
Internet Draft Juniper Networks
Expiration Date: August 2004 Liming Wei
George Apostolopoulos
Redback Networks
Kireeti Kompella
Juniper Networks
John Drake
Calient Networks
Establishing Point to Multipoint MPLS TE LSPs
draft-raggarwa-mpls-p2mp-te-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 1]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
Abstract
This document describes a solution for point to multipoint (P2MP)
Traffic Engineering (TE). The objective is to optimize packet
replication and minimize state and intelligence in the core of the
network, while performing P2MP TE. The solution relies on RSVP-TE in
the core of the network. It is based on setting up a P2MP LSP by
merging P2P LSPs in the network. The setup of P2P LSPs is source
intiated. Simple enhancements are made to RSVP-TE to facilitate the
set up of a P2MP TE LSP. There is no need to run a multicast routing
protocol in the network core. There can be various applications for
P2MP TE LSPs such as multicast. Specification of how such
applications will use a P2MP LSP is outside the scope of this
document.
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 [KEYWORDS].
Table of Contents
1 Introduction........................................ 3
2 Terminology......................................... 3
3 Problem Statement................................... 4
4 Mechanism........................................... 4
4.1 Spe Initiated Branch LSPs........................... 5
4.2 P2MP LSP Session Object............................. 5
4.2.1 P2MP IPv4 LSP Session Object........................ 6
4.2.2 P2MP IPv6 LSP Session Object........................ 7
4.3 Sender Template..................................... 7
4.3.1 P2MP IPv4 Branch LSP Sender Template Object......... 7
4.3.2 P2MP IPv6 Branch LSP Sender Template Object......... 8
4.4 Example............................................. 8
4.4.1 Spe Initiated Branch LSPs........................... 8
5 Rpe Discovery....................................... 9
6 Label Allocation on LANs with Multiple Downstream Nodes 9
7 Signaling Considerations............................ 9
7.1 Non-Adjacent Signaling for branch LSPs.............. 10
8 Path Computation.................................... 10
9 Make-before-break and Fast Reroute.................. 11
9.1 Make-before-break................................... 11
9.2 Fast Reroute........................................ 11
9.2.1 Facility Backup..................................... 11
9.2.2 One to One Backup................................... 12
draft-raggarwa-mpls-p2mp-te-01.txt [Page 2]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
10 LSP Hierarchy Using P2P LSPs........................ 12
10.1 Reduction in Control Plane PRocessing............... 13
10.2 Support for LSRs that are not P2MP Capable.......... 13
11 IANA Considerations................................. 13
12 Security Considerations............................. 14
13 Acknowledgements.................................... 14
14 References.......................................... 14
1. Introduction
[RSVP-TE] defines a mechanism for setting up point to point (P2P) TE
tunnels. It does not provide a mechanism for building point to
multipoint TE tunnels. However [RSVP-TE] is built on [RSVP] which
does have mechanisms for supporting multiple receivers for the same
session. This document describes how RSVP-TE can be used for P2MP
TE. It relies on the semantics of RSVP that RSVP-TE inherits for
building a P2MP TE tree. P2P TE LSPs are set up between the source
and receiver PEs. These P2P TE LSPs are appropriately merged by the
network using RSVP semantics to result in a P2MP TE LSP. The P2P LSPs
are initiated using RSVP-TE by the PE attached to the source. MPLS
label FIB is enhanced to support multicast of MPLS packets at the
nodes where the P2P LSPs merge.
2. Terminology
Source-PE (Spe): This is the PE that is connected to the traffic
source. For instance this may be the multicast source.
Receiver-PE (Rpe): This is the PE that is connected to one or more
receivers. For instance these may be multicast receivers.
P2MP-ID (Pid): This is the ID that can be used to map a set of Rpes
to a P2MP tree for a particular application. Its usage is application
dependent.
Branch LSP: A P2P TE LSP that is a constituent of a P2MP TE LSP. A
P2MP TE LSP is constituted of one or more branch LSPs.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 3]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
3. Problem Statement
Source 1 (S1)
|
PE1
| |
| |
P3 |
| |
| |
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
|
PE4----R3
|
|
R4
Figure 1.
The above figure shows PE1, PE2, PE3 and PE4. PE1 is the source-PE;
PE2, PE3 and PE4 are receiver-PEs. The following are the objectives
that we wish to achieve:
a) Set up a P2MP TE LSP from PE1 to PE2, PE3 and PE4, where each Rpe
is free to choose the QoS it desires. b) Follow RSVP-TE procedures
with as little enhancements as possible while setting the P2MP LSP.
c) Map a P2MP LSP to a Spe and a Pid, with the flexibility to setup
multiple LSPs for the same Pid.
4. Mechanism
It is desirable to achieve the objectives described in section 3
without running a multicast routing protocol in the network core. An
obvious solution is to set up a full mesh of RSVP-TE P2P tunnels and
replicate a packet intended, for a set of Rpes, at the Spe. This has
the obvious disadvantage of replication only at the edge of the
network. This can be improved by creating a network topology with
RSVP-TE mesh in a certain part of the core surrounded by routers
running a multicast routing protocol. However even this is not
optimal and adds significant complexity.
We describe a solution that uses RSVP-TE in the core of the network
for setting up a P2MP TE LSP. The P2MP TE LSP is set up by merging
individual P2P TE LSPs and relying on MPLS label multicast. The P2P
TE LSPs that are merged to form the P2MP TE LSP are termed as branch
LSPs. The branch LSPs are initiated by the Spe. Hence the solution
draft-raggarwa-mpls-p2mp-te-01.txt [Page 4]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
is as efficent as trees setup by a multicast routing protocol in an
IP environment. This is achieved without burdening RSVP-TE with any
of the mechanisms of a multicast routing protocol.
Section 4.1 describes the steps as per this solution for achieving
the objectives outlined in section 3 when the branch LSPs are Spe
initiated.
4.1. Spe Initiated Branch LSPs
In this case the Spe is aware of all the Rpes interested in a given
Pid. For instance the Pid may be a multicast group that all the Rpes
are interested in. How the Spe discovers this is application
dependent and should be specified in the application specific
documents. The following are the procedures followed by the Spe to
setup a P2MP LSP that is mapped to a particular Pid.
a) The Spe initiates the set up of a RSVP-TE Branch LSP to each Rpe
that is the destination of the P2MP LSP. Each branch LSP is
associated with the same P2MP LSP. Hence it can merge with other
branch LSPs to form a P2MP LSP. A new P2MP session object is
introduced for this purpose. The branch LSP is signaled with shared
semantics. Hence another branch LSP belonging to the same session can
share resources with this LSP. The session is determined based on the
new RSVP-TE P2MP session object. Each branch LSP is identified using
the sender template. A new P2MP sender template is introduced. The
PATH message for each branch LSP carries the explicit route object.
b) At each hop the RSVP-TE PATH message is processed using normal
RSVP-TE procedures.
c) The Rpe follows normal RSVP procedures while originating a RESV
message. It can indicate a different QoS in the RESV from that
received in the PATH message as long as the new QoS is lower. The
RESV message carries the label allocated by the Rpe.
d) A subsequent node allocates its own label and passes it in the
RESV message. Each of the RESV messages, for a given session,
received from downtstream that use the same interface to reach the
upstream next hop are allocated the same label. This label is the
"multicast label". This multicast label is associated by that node
with all the labels received from downstream RESV messages for that
session. A multicast label mapping is appropriately created at each
node. Hence this results in the setup of a P2MP LSP from the Spe to
the Rpes.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 5]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
4.2. P2MP LSP Session Object
A new P2MP LSP session object is defined in RSVP-TE. It is possible
to simply use the existing RSVP-TE sssion object and indicate a P2MP
LSP using session attributes. However its conceptually simpler and
also easier for an implementation to associate the semantics for P2MP
MPLS with a new session object. This new session object has a similar
structure as the existing point to point RSVP-TE session object. All
branch LSPs share the same session object.
4.2.1. P2MP IPv4 LSP Session Object
Class = SESSION, LSP_P2MP_TUNNEL_IPv4 C-Type = TBD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Spe Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Spe Address
IPv4 address of the Spe. An implementation may use the router ID
for
this purpose. It is to be noted the corresponding field in P2P
RSVP-TE
session object is the destination address of the session. The
destination address of a P2MP branch LSP will be determined from
the
sender template as described below.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
P2MP ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. It encodes the Pid.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 6]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
4.2.2. P2MP IPv6 LSP Session Object
Class = SESSION, LSP_P2MP_TUNNEL_IPv6 C-Type = TBD
This is same as the P2MP IPv4 LSP Session Object with the difference
that the Spe Address is a 16 byte IPv6 address.
4.3. Sender Template
The sender template identifies a particular branch LSP belonging to
the P2MP LSP.
4.3.1. P2MP IPv4 Branch LSP Sender Template Object
Class = SENDER_TEMPLATE, P2MP_LSP_BRANCH_IPv4 C-Type = TBD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 branch LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Branch ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
IPv4 address of the branch LSP destination.
LSP ID
A 16-bit identifier that can be changed to allow a sender to share
resources with itself. Thus multiple instances of the P2MP tunnel
can be created, each with a different LSP ID. The instances can
share resources with each other, but use different labels. The
branch LSPs corresponding to a particular instance use the same
LSP ID.
Branch ID
A 16-bit identifier that identifies a particular branch LSP.
Different branch LSPs, with the same LSP ID, follow the label
merge semantics described in section 4.1 to form a particular
instance of the P2MP tunnel.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 7]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
4.3.2. P2MP IPv6 Branch LSP Sender Template Object
Class = SENDER_TEMPLATE, P2MP_LSP_BRANCH_IPv6 C-Type = TBD
This is same as the P2MP IPv4 Branch LSP Sender Template Object, with
the difference that the destination address is a 16 byte IPv6
address.
4.4. Example
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE4----R3
|
|
R4
Figure 2.
The mechanism is explained using Figure 2. PE1 is the Spe. PE3 and
PE4 are Rpes in VPN1.
4.4.1. Spe Intiated P2P LSPs
a) PE1 learns that PE2, PE3 and PE4 are interested in joining a P2MP
tree with a Pid of VPN1. PE1 may learn of the Rpes at different
points, though in this example we will assume that it learns the Rpes
at the same time. b) PE1 computes the P2P paths to reach PE2, PE3
and PE4. These paths are computed to share the same links where
possible as they belong to the same session. c) PE1 sends a PATH
message for each branch LSP. d) PE2, PE3 and PE4 respond with a RESV
message. e) P1 receives a RESV message from PE3 with label L3 and
from PE4 with label L4. It allocates a label L1 and sends the RESV
messages to P3. It also creates a multicast label mapping of (L1 ->
{L3, L4}). P3 allocates a label L5 and sends the RESV messages to
PE1, each with label L5. It creates a label mapping of {L5 -> L1}.
f) PE1 also receives a RESV from P2 with a label of L2.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 8]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
5. Rpe Discovery
For Spe intiated P2P LSPs, the Spe has to discover all the Rpes
interested in a given P2MP tree i.e. a particular Pid. Such discovery
is application depenedent and should be specified in the application
specific documents.
6. Label Allocation on LANs with Multiple Downstream Nodes
A sender on a LAN uses a different label for sending a packet to each
node on the LAN that belongs to the P2MP LSP. Thus the sender
performs packet replication. It may be considered desirable on a LAN
to use the same label for sending a packet to multiple nodes
belonging to the same P2MP LSP, to avoid packet replication. Given
the relatively small number of LANs in MPLS networks, this is not
seen as a practical problem. Furthermore avoiding packet replication
at the sender on a LAN requires significant complexity in the control
plane. Given the tradeoff we propose the use of packet replication by
the sender on a LAN.
7. Signaling Considerations
As mentioned earlier, in this approach, individual branch LSPs merge
to form a P2MP LSP. A separate PATH message, with an explicit route
object, is sent for each branch LSP. Hence RSVP-TE is not burdened
with P2MP explicit routes. This has the advantage of keeping RSVP-TE
procedures as close as possible to existing TE procedures for P2P
LSPs. It reduces complexity and makes it easier to enhance existing
and deployed RSVP-TE implementations to support P2MP TE LSPs. RSVP
refresh reduction [RSVP-RR] can be used to reduce the signaling
overhead.
Below we describe how non-adjacent signaling can be used to reduce
PATH message processing and state on nodes that are along the commong
path of two or more branch LSPs. Section 10 also describes how LSP
hierarchy can be used to reduce P2MP control plane processing on
transit LSRs.
7.1. Non-adjacent Signaling for Branch LSPs
As described in section 4.1, a separate PATH message has to be
processed for a branch LSP by each node along the explicit route of
the branch LSP. This is indeed true for the first branch LSP to be
setup along a given explicit route. The next branch LSP may follow
the same path as the first branch LSP upto a certain branch LSR.
There is no need for routers along this common path to process the
draft-raggarwa-mpls-p2mp-te-01.txt [Page 9]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
PATH message corresponding to the second branch LSP. The same holds
true for successive branch LSPs. The P2MP LSP ingress can send the
PATH message directly to the branch LSR where the second branch LSP
branches from the first one. The ERO will contain hops along the path
beyond the branch LSR. Furthermore a Label Request object is not
inserted in such a PATH message. This mechanism is also referred to
as non-adjacent signaling. This is done by sending the PATH message
directly to the branch LSR as described in [LSP-HIER]. Hence while
sending the PATH message for a particular branch LSP, the P2MP
ingress can determine the first branch LSR where the path of this
branch LSP, branches from the existing P2MP LSP. It can then use non-
adjacent signaling to send the PATH message to the branch LSR. The
branch LSR in turn, will send the RESV message directly to the
ingress.
Hence with respect to figure 2, assume that PE1 sets up the branch
LSP to PE3 first followed by the branch LSP to PE4. In this case the
PATH message for the branch LSP to PE4, can be sent directly to P1,
bypassing P3.
This mechanism reduces PATH message processing and state along nodes
that are on the common path of two or more branch LSPs.
8. Path Computation
A Spe when setting a P2MP LSP has a view of the entire network
topology and can accordingly compute the path for each P2P LSP,
sharing links where possible with other branch LSPs belonging to the
P2MP LSP. This can also be described as a P2MP CSPF, where a path to
a Rpe is set up as a P2P LSP. Details of such a CSPF algorithm are
beyond the scope of this document.
9. Make-before-break and Fast Reroute
The building blocks for the mechanism described in this document are
P2P LSPs that constitute the P2MP LSP. A big advantage of this is
that Rpes can be added/removed very flexibly without disturbing rest
of the network. This advantage also carries over to make-before-break
and fast reroute.
9.1. Make before break
Let's consider the following cases where make-before-break is needed:
1. P2MP Tree re-optimization at the Spe. In this case all the branch
LSPs are signaled with a different LSP ID and follow the normal RSVP-
draft-raggarwa-mpls-p2mp-te-01.txt [Page 10]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
TE make-before-break procedure. Thus a new instance of the P2MP
tunnel is established. The ingress can, after moving traffic to the
new instance, tear down the previous P2MP tunnel instance.
2. Re-optimization of one or more branch LSPs. In this case each re-
optimized branch LSP is signaled with a different branch ID and hence
a new branch LSP is established. Once the new setup is complete, the
old branch LSP can be torn down.
3. A link failure in the network. In this case all the branch LSPs
that are effected by the link failure are re-routed. Local repair is
initiated to protect the constituent branch LSPs.
9.2. Fast Reroute
[RSVP-FR] extensions can be used to perform fast reroute for the
mechanism described in this document.
9.2.1. Facility Backup
Facility backup as described in [RSVP-FR] can be used to protect a
set of branch LSPs, potentially belonging to different P2MP LSPs.
If link protection is desired, a bypass tunnel is used to protect the
link between the PLR and next-hop. Thus all branch LSPs that use the
link can be protected in the event of link failure. Note that all
such branch LSPs belonging to a particular instance of a P2MP tunnel
will share the same outgoing label on the link between the PLR and
the next-hop. This is the P2MP LSP label on the link. Label stacking
is used to send packets for each P2MP LSP in the bypass tunnel. The
inner label is the P2MP LSP label allocated by the nhop. During
failure PATH messages for each branch LSP, that is effected, will be
sent to the MP, by the PLR. It is recommended that the PLR use the
sender template specific method to identify these PATH messages.
Hence the PLR will set the branch LSP destination address to a local
PLR address. The MP will determine the protected branch LSP using the
LSP-id and the branch-id.
If node protection is desired, the bypass tunnel must intersect the
path of the protected branch LSPs somewhere downstream of the PLR.
This constrains the set of branch LSPs being backed-up via that
bypass tunnel to those that pass through a common downstream MP. The
MP will allocate the same label to all such branch LSPs belonging to
a particular instance of a P2MP tunnel. This will be the inner label
used during label stacking.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 11]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
9.2.2. One to One Backup
One to one backup as described in [RSVP-FR] can be used to protect a
particular branch LSP against link and next-hop failure. Protection
may be used for one or more branch LSPs between the PLR and the next-
hop. All the branch LSPs corresponding to the same instance of the
P2MP tunnel, between the PLR and the next-hop share the same P2MP LSP
label. All or some of these branch LSPs may be protected. The detour
branch LSPs may or may not share labels, depending on the detour
path. Thus the set of outgoing labels and next-hops for a P2MP LSP
that was using a single next-hop and label between the PLR and next-
hop before protection, may change once protection is triggerred.
Its is recommended that the path specific method be used to identify
a backup branch LSP. Hence the DETOUR object will be inserted in the
backup PATH message. A backup branch LSP MUST be treated as belonging
to a different P2MP tunnel instance than the one specified by the
LSP-id. Furthermore multiple backup branch LSPs MUST be treated as
part of the same P2MP tunnel instance if they have the same LSP-id
and the same DETOUR objects. Note that as specified in section 4.3
branch LSPs between different P2MP tunnel instances use different
labels.
10. LSP Hierarchy Using P2P LSPs
It is possible to take advantage of LSP hierarchy [LSP-HIER] while
building P2MP LSPs. One mechanism to do this is the use of P2P LSPs
as links of the P2MP LSP. A P2P LSP can be advertised as a Forwarding
Adjacency (FA) by the ingress of the P2P LSP. The FA can then be used
by the headend of the P2MP LSP while computing the path of each
branch LSP. If a FA is used by a branch LSP the corresponding ERO
contains a list of objects upto the FA head-end followed by a loose
object with the address of the FA tail-end. The FA head-end on
receiving the branch LSP PATH message determines the FA from its
Traffic Engineering Database (TED) and tunnels the PATH message over
the FA. The FA tail-end on receiving the PATH message follows
procedures specified in previous sections. The FA tail-end sends a
RESV message to the FA head-end with a P2MP LSP label. The RESV
message is sent using the procedures in [LSP-HIER]. For example in
Figure 2, PE1 can setup a P2P LSP to P1 and use that as a FA. The
PATH messages for PE3 and PE4 can now be tunneled over the FA. Thus
P3 is not aware of the P2MP LSP and does not process the P2MP control
messages.
LSP hierearchy as described above has several advantages, some of
which are discussed below.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 12]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
10.1. Reduction in Control Plane Processing
Transit LSRs along a FA, being used by a P2MP LSP, do not process
control plane messages associated with the P2MP LSP. Infact they are
not aware of these messages as they are tunneled over the FA. This
reduces the amount of control plane processing required on these
transit LSRs. Hence the use of P2P LSPs as FAs can increase the
overall control plane scalability while setting up P2MP LSPs.
10.2. Support for LSRs that are not P2MP Capable
Its conceivable that some LSRs, in a network deploying P2MP MPLS TE,
may not be capable of P2MP MPLS. The use of FAs allows to build P2MP
LSPs in such an environment. As mentioned above transit LSRs along a
FA do not process control plane messages associated with a P2MP LSP.
Futhermore these LSRs also do not need to have P2MP MPLS data plane
capability as they only need to process MPLS data plane packets
belonging to the P2P LSP that is being used as a FA. Hence these LSRs
do not need to support P2MP MPLS. It is to be noted that such LSRs
can not act as branch points along the P2MP LSP.
11. IANA Considerations
This document requires the use of a RSVP-TE P2MP session object and a
RSVP-TE P2MP branch LSP sender template object. The C-Types for these
objects have to be assigned by IANA.
12. Security Considerations
This document does not introduce any new security issues. The
security issues identified in [RSVP-TE] are still relevant.
13. Acknowledgements
We would like to thank George Swallow for his contribution and
suggestions. Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger
and Nischal Sheth for their suggestions and comments. Thanks also to
Dino Farninacci for his comments.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 13]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
14. References
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001
[RFC] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997.
[GMPLS] Lou Berger, et al., "Generalized MPLS - Signaling Functional
Description", draft-ietf-mpls-generalized-signaling-08.txt,
April 2002
[G-RSVP] L. Berger, "Generalized MPLS Signaling - RSVP-TE Extensions",
draft-ietf-mpls-generalized-rsvp-te-09.txt, September 2002.
[RSVP-RR] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001.
[RSVP-FR] P. Pan, D. Gan, G. Swallow, J. P. Vasseur, D. Cooper,
A. Atlas, M. Jork, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt.
[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt.
Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Liming Wei
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: lwei@redback.com
draft-raggarwa-mpls-p2mp-te-01.txt [Page 14]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
George Apostolopoulos
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: georgeap@redback.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: kireeti@juniper.net
John Drake
Calient Networks
Email: jdrake@calient.net
IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 15]
Internet Draft draft-raggarwa-mpls-p2mp-te-01.txt January 2004
Full Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
draft-raggarwa-mpls-p2mp-te-01.txt [Page 16]
Network Working Group Rahul Aggarwal (Editor)
Internet Draft Juniper Networks
Expiration Date: August 2004 Liming Wei
George Apostolopoulos
Redback Networks
Kireeti Kompella
Juniper Networks
John Drake
Calient Networks
Establishing Point to Multipoint MPLS TE LSPs
draft-raggarwa-mpls-p2mp-te-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 1]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
Abstract
This document describes a solution for point to multipoint (P2MP)
Traffic Engineering (TE). The objective is to optimize packet
replication and minimize state and intelligence in the core of the
network, while performing P2MP TE. The solution relies on RSVP-TE in
the core of the network. It is based on setting up a P2MP LSP by
merging P2P LSPs in the network. The setup of P2P LSPs is source
intiated. Simple enhancements are made to RSVP-TE to facilitate the
set up of a P2MP TE LSP. There is no need to run a multicast routing
protocol in the network core. There can be various applications for
P2MP TE LSPs such as multicast. Specification of how such
applications will use a P2MP LSP is outside the scope of this
document.
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 [KEYWORDS].
Table of Contents
1 Introduction........................................ 3
2 Terminology......................................... 3
3 Problem Statement................................... 4
4 Mechanism........................................... 4
4.1 Spe Initiated Branch LSPs........................... 5
4.2 P2MP LSP Session Object............................. 5
4.2.1 P2MP IPv4 LSP Session Object........................ 6
4.2.2 P2MP IPv6 LSP Session Object........................ 7
4.3 Sender Template..................................... 7
4.3.1 P2MP IPv4 Branch LSP Sender Template Object......... 7
4.3.2 P2MP IPv6 Branch LSP Sender Template Object......... 8
4.4 Example............................................. 8
4.4.1 Spe Initiated Branch LSPs........................... 8
5 Rpe Discovery....................................... 9
6 Label Allocation on LANs with Multiple Downstream Nodes 9
7 Signaling Considerations............................ 9
7.1 Non-Adjacent Signaling for branch LSPs.............. 10
8 Path Computation.................................... 10
9 Make-before-break and Fast Reroute.................. 11
9.1 Make-before-break................................... 11
9.2 Fast Reroute........................................ 11
9.2.1 Facility Backup..................................... 11
9.2.2 One to One Backup................................... 12
draft-raggarwa-mpls-p2mp-te-00.txt [Page 2]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
10 LSP Hierarchy Using P2P LSPs........................ 12
10.1 Reduction in Control Plane PRocessing............... 13
10.2 Support for LSRs that are not P2MP Capable.......... 13
11 IANA Considerations................................. 13
12 Security Considerations............................. 14
13 Acknowledgements.................................... 14
14 References.......................................... 14
1. Introduction
[RSVP-TE] defines a mechanism for setting up point to point (P2P) TE
tunnels. It does not provide a mechanism for building point to
multipoint TE tunnels. However [RSVP-TE] is built on [RSVP] which
does have mechanisms for supporting multiple receivers for the same
session. This document describes how RSVP-TE can be used for P2MP
TE. It relies on the semantics of RSVP that RSVP-TE inherits for
building a P2MP TE tree. P2P TE LSPs are set up between the source
and receiver PEs. These P2P TE LSPs are appropriately merged by the
network using RSVP semantics to result in a P2MP TE LSP. The P2P LSPs
are initiated using RSVP-TE by the PE attached to the source. MPLS
label FIB is enhanced to support multicast of MPLS packets at the
nodes where the P2P LSPs merge.
2. Terminology
Source-PE (Spe): This is the PE that is connected to the traffic
source. For instance this may be the multicast source.
Receiver-PE (Rpe): This is the PE that is connected to one or more
receivers. For instance these may be multicast receivers.
P2MP-ID (Pid): This is the ID that can be used to map a set of Rpes
to a P2MP tree for a particular application. Its usage is application
dependent.
Branch LSP: A P2P TE LSP that is a constituent of a P2MP TE LSP. A
P2MP TE LSP is constituted of one or more branch LSPs.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 3]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
3. Problem Statement
Source 1 (S1)
|
PE1
| |
| |
P3 |
| |
| |
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
|
PE4----R3
|
|
R4
Figure 1.
The above figure shows PE1, PE2, PE3 and PE4. PE1 is the source-PE;
PE2, PE3 and PE4 are receiver-PEs. The following are the objectives
that we wish to achieve:
a) Set up a P2MP TE LSP from PE1 to PE2, PE3 and PE4, where each Rpe
is free to choose the QoS it desires. b) Follow RSVP-TE procedures
with as little enhancements as possible while setting the P2MP LSP.
c) Map a P2MP LSP to a Spe and a Pid, with the flexibility to setup
multiple LSPs for the same Pid.
4. Mechanism
It is desirable to achieve the objectives described in section 3
without running a multicast routing protocol in the network core. An
obvious solution is to set up a full mesh of RSVP-TE P2P tunnels and
replicate a packet intended, for a set of Rpes, at the Spe. This has
the obvious disadvantage of replication only at the edge of the
network. This can be improved by creating a network topology with
RSVP-TE mesh in a certain part of the core surrounded by routers
running a multicast routing protocol. However even this is not
optimal and adds significant complexity.
We describe a solution that uses RSVP-TE in the core of the network
for setting up a P2MP TE LSP. The P2MP TE LSP is set up by merging
individual P2P TE LSPs and relying on MPLS label multicast. The P2P
TE LSPs that are merged to form the P2MP TE LSP are termed as branch
LSPs. The branch LSPs are initiated by the Spe. Hence the solution
draft-raggarwa-mpls-p2mp-te-00.txt [Page 4]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
is as efficent as trees setup by a multicast routing protocol in an
IP environment. This is achieved without burdening RSVP-TE with any
of the mechanisms of a multicast routing protocol.
Section 4.1 describes the steps as per this solution for achieving
the objectives outlined in section 3 when the branch LSPs are Spe
initiated.
4.1. Spe Initiated Branch LSPs
In this case the Spe is aware of all the Rpes interested in a given
Pid. For instance the Pid may be a multicast group that all the Rpes
are interested in. How the Spe discovers this is application
dependent and should be specified in the application specific
documents. The following are the procedures followed by the Spe to
setup a P2MP LSP that is mapped to a particular Pid.
a) The Spe initiates the set up of a RSVP-TE Branch LSP to each Rpe
that is the destination of the P2MP LSP. Each branch LSP is
associated with the same P2MP LSP. Hence it can merge with other
branch LSPs to form a P2MP LSP. A new P2MP session object is
introduced for this purpose. The branch LSP is signaled with shared
semantics. Hence another branch LSP belonging to the same session can
share resources with this LSP. The session is determined based on the
new RSVP-TE P2MP session object. Each branch LSP is identified using
the sender template. A new P2MP sender template is introduced. The
PATH message for each branch LSP carries the explicit route object.
b) At each hop the RSVP-TE PATH message is processed using normal
RSVP-TE procedures.
c) The Rpe follows normal RSVP procedures while originating a RESV
message. It can indicate a different QoS in the RESV from that
received in the PATH message as long as the new QoS is lower. The
RESV message carries the label allocated by the Rpe.
d) A subsequent node allocates its own label and passes it in the
RESV message. Each of the RESV messages, for a given session,
received from downtstream that use the same interface to reach the
upstream next hop are allocated the same label. This label is the
"multicast label". This multicast label is associated by that node
with all the labels received from downstream RESV messages for that
session. A multicast label mapping is appropriately created at each
node. Hence this results in the setup of a P2MP LSP from the Spe to
the Rpes.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 5]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
4.2. P2MP LSP Session Object
A new P2MP LSP session object is defined in RSVP-TE. It is possible
to simply use the existing RSVP-TE sssion object and indicate a P2MP
LSP using session attributes. However its conceptually simpler and
also easier for an implementation to associate the semantics for P2MP
MPLS with a new session object. This new session object has a similar
structure as the existing point to point RSVP-TE session object. All
branch LSPs share the same session object.
4.2.1. P2MP IPv4 LSP Session Object
Class = SESSION, LSP_P2MP_TUNNEL_IPv4 C-Type = TBD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Spe Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Spe Address
IPv4 address of the Spe. An implementation may use the router ID
for
this purpose. It is to be noted the corresponding field in P2P
RSVP-TE
session object is the destination address of the session. The
destination address of a P2MP branch LSP will be determined from
the
sender template as described below.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
P2MP ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. It encodes the Pid.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 6]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
4.2.2. P2MP IPv6 LSP Session Object
Class = SESSION, LSP_P2MP_TUNNEL_IPv6 C-Type = TBD
This is same as the P2MP IPv4 LSP Session Object with the difference
that the Spe Address is a 16 byte IPv6 address.
4.3. Sender Template
The sender template identifies a particular branch LSP belonging to
the P2MP LSP.
4.3.1. P2MP IPv4 Branch LSP Sender Template Object
Class = SENDER_TEMPLATE, P2MP_LSP_BRANCH_IPv4 C-Type = TBD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 branch LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Branch ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
IPv4 address of the branch LSP destination.
LSP ID
A 16-bit identifier that can be changed to allow a sender to share
resources with itself. Thus multiple instances of the P2MP tunnel
can be created, each with a different LSP ID. The instances can
share resources with each other, but use different labels. The
branch LSPs corresponding to a particular instance use the same
LSP ID.
Branch ID
A 16-bit identifier that identifies a particular branch LSP.
Different branch LSPs, with the same LSP ID, follow the label
merge semantics described in section 4.1 to form a particular
instance of the P2MP tunnel.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 7]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
4.3.2. P2MP IPv6 Branch LSP Sender Template Object
Class = SENDER_TEMPLATE, P2MP_LSP_BRANCH_IPv6 C-Type = TBD
This is same as the P2MP IPv4 Branch LSP Sender Template Object, with
the difference that the destination address is a 16 byte IPv6
address.
4.4. Example
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE4----R3
|
|
R4
Figure 2.
The mechanism is explained using Figure 2. PE1 is the Spe. PE3 and
PE4 are Rpes in VPN1.
4.4.1. Spe Intiated P2P LSPs
a) PE1 learns that PE2, PE3 and PE4 are interested in joining a P2MP
tree with a Pid of VPN1. PE1 may learn of the Rpes at different
points, though in this example we will assume that it learns the Rpes
at the same time. b) PE1 computes the P2P paths to reach PE2, PE3
and PE4. These paths are computed to share the same links where
possible as they belong to the same session. c) PE1 sends a PATH
message for each branch LSP. d) PE2, PE3 and PE4 respond with a RESV
message. e) P1 receives a RESV message from PE3 with label L3 and
from PE4 with label L4. It allocates a label L1 and sends the RESV
messages to P3. It also creates a multicast label mapping of (L1 ->
{L3, L4}). P3 allocates a label L5 and sends the RESV messages to
PE1, each with label L5. It creates a label mapping of {L5 -> L1}.
f) PE1 also receives a RESV from P2 with a label of L2.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 8]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
5. Rpe Discovery
For Spe intiated P2P LSPs, the Spe has to discover all the Rpes
interested in a given P2MP tree i.e. a particular Pid. Such discovery
is application depenedent and should be specified in the application
specific documents.
6. Label Allocation on LANs with Multiple Downstream Nodes
A sender on a LAN uses a different label for sending a packet to each
node on the LAN that belongs to the P2MP LSP. Thus the sender
performs packet replication. It may be considered desirable on a LAN
to use the same label for sending a packet to multiple nodes
belonging to the same P2MP LSP, to avoid packet replication. Given
the relatively small number of LANs in MPLS networks, this is not
seen as a practical problem. Furthermore avoiding packet replication
at the sender on a LAN requires significant complexity in the control
plane. Given the tradeoff we propose the use of packet replication by
the sender on a LAN.
7. Signaling Considerations
As mentioned earlier, in this approach, individual branch LSPs merge
to form a P2MP LSP. A separate PATH message, with an explicit route
object, is sent for each branch LSP. Hence RSVP-TE is not burdened
with P2MP explicit routes. This has the advantage of keeping RSVP-TE
procedures as close as possible to existing TE procedures for P2P
LSPs. It reduces complexity and makes it easier to enhance existing
and deployed RSVP-TE implementations to support P2MP TE LSPs. RSVP
refresh reduction [RSVP-RR] can be used to reduce the signaling
overhead.
Below we describe how non-adjacent signaling can be used to reduce
PATH message processing and state on nodes that are along the commong
path of two or more branch LSPs. Section 10 also describes how LSP
hierarchy can be used to reduce P2MP control plane processing on
transit LSRs.
7.1. Non-adjacent Signaling for Branch LSPs
As described in section 4.1, a separate PATH message has to be
processed for a branch LSP by each node along the explicit route of
the branch LSP. This is indeed true for the first branch LSP to be
setup along a given explicit route. The next branch LSP may follow
the same path as the first branch LSP upto a certain branch LSR.
There is no need for routers along this common path to process the
draft-raggarwa-mpls-p2mp-te-00.txt [Page 9]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
PATH message corresponding to the second branch LSP. The same holds
true for successive branch LSPs. The P2MP LSP ingress can send the
PATH message directly to the branch LSR where the second branch LSP
branches from the first one. The ERO will contain hops along the path
beyond the branch LSR. Furthermore a Label Request object is not
inserted in such a PATH message. This mechanism is also referred to
as non-adjacent signaling. This is done by sending the PATH message
directly to the branch LSR as described in [LSP-HIER]. Hence while
sending the PATH message for a particular branch LSP, the P2MP
ingress can determine the first branch LSR where the path of this
branch LSP, branches from the existing P2MP LSP. It can then use non-
adjacent signaling to send the PATH message to the branch LSR. The
branch LSR in turn, will send the RESV message directly to the
ingress.
Hence with respect to figure 2, assume that PE1 sets up the branch
LSP to PE3 first followed by the branch LSP to PE4. In this case the
PATH message for the branch LSP to PE4, can be sent directly to P1,
bypassing P3.
This mechanism reduces PATH message processing and state along nodes
that are on the common path of two or more branch LSPs.
8. Path Computation
A Spe when setting a P2MP LSP has a view of the entire network
topology and can accordingly compute the path for each P2P LSP,
sharing links where possible with other branch LSPs belonging to the
P2MP LSP. This can also be described as a P2MP CSPF, where a path to
a Rpe is set up as a P2P LSP. Details of such a CSPF algorithm are
beyond the scope of this document.
9. Make-before-break and Fast Reroute
The building blocks for the mechanism described in this document are
P2P LSPs that constitute the P2MP LSP. A big advantage of this is
that Rpes can be added/removed very flexibly without disturbing rest
of the network. This advantage also carries over to make-before-break
and fast reroute.
9.1. Make before break
Let's consider the following cases where make-before-break is needed:
1. P2MP Tree re-optimization at the Spe. In this case all the branch
LSPs are signaled with a different LSP ID and follow the normal RSVP-
draft-raggarwa-mpls-p2mp-te-00.txt [Page 10]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
TE make-before-break procedure. Thus a new instance of the P2MP
tunnel is established. The ingress can, after moving traffic to the
new instance, tear down the previous P2MP tunnel instance.
2. Re-optimization of one or more branch LSPs. In this case each re-
optimized branch LSP is signaled with a different branch ID and hence
a new branch LSP is established. Once the new setup is complete, the
old branch LSP can be torn down.
3. A link failure in the network. In this case all the branch LSPs
that are effected by the link failure are re-routed. Local repair is
initiated to protect the constituent branch LSPs.
9.2. Fast Reroute
[RSVP-FR] extensions can be used to perform fast reroute for the
mechanism described in this document.
9.2.1. Facility Backup
Facility backup as described in [RSVP-FR] can be used to protect a
set of branch LSPs, potentially belonging to different P2MP LSPs.
If link protection is desired, a bypass tunnel is used to protect the
link between the PLR and next-hop. Thus all branch LSPs that use the
link can be protected in the event of link failure. Note that all
such branch LSPs belonging to a particular instance of a P2MP tunnel
will share the same outgoing label on the link between the PLR and
the next-hop. This is the P2MP LSP label on the link. Label stacking
is used to send packets for each P2MP LSP in the bypass tunnel. The
inner label is the P2MP LSP label allocated by the nhop. During
failure PATH messages for each branch LSP, that is effected, will be
sent to the MP, by the PLR. It is recommended that the PLR use the
sender template specific method to identify these PATH messages.
Hence the PLR will set the branch LSP destination address to a local
PLR address. The MP will determine the protected branch LSP using the
LSP-id and the branch-id.
If node protection is desired, the bypass tunnel must intersect the
path of the protected branch LSPs somewhere downstream of the PLR.
This constrains the set of branch LSPs being backed-up via that
bypass tunnel to those that pass through a common downstream MP. The
MP will allocate the same label to all such branch LSPs belonging to
a particular instance of a P2MP tunnel. This will be the inner label
used during label stacking.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 11]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
9.2.2. One to One Backup
One to one backup as described in [RSVP-FR] can be used to protect a
particular branch LSP against link and next-hop failure. Protection
may be used for one or more branch LSPs between the PLR and the next-
hop. All the branch LSPs corresponding to the same instance of the
P2MP tunnel, between the PLR and the next-hop share the same P2MP LSP
label. All or some of these branch LSPs may be protected. The detour
branch LSPs may or may not share labels, depending on the detour
path. Thus the set of outgoing labels and next-hops for a P2MP LSP
that was using a single next-hop and label between the PLR and next-
hop before protection, may change once protection is triggerred.
Its is recommended that the path specific method be used to identify
a backup branch LSP. Hence the DETOUR object will be inserted in the
backup PATH message. A backup branch LSP MUST be treated as belonging
to a different P2MP tunnel instance than the one specified by the
LSP-id. Furthermore multiple backup branch LSPs MUST be treated as
part of the same P2MP tunnel instance if they have the same LSP-id
and the same DETOUR objects. Note that as specified in section 4.3
branch LSPs between different P2MP tunnel instances use different
labels.
10. LSP Hierarchy Using P2P LSPs
It is possible to take advantage of LSP hierarchy [LSP-HIER] while
building P2MP LSPs. One mechanism to do this is the use of P2P LSPs
as links of the P2MP LSP. A P2P LSP can be advertised as a Forwarding
Adjacency (FA) by the ingress of the P2P LSP. The FA can then be used
by the headend of the P2MP LSP while computing the path of each
branch LSP. If a FA is used by a branch LSP the corresponding ERO
contains a list of objects upto the FA head-end followed by a loose
object with the address of the FA tail-end. The FA head-end on
receiving the branch LSP PATH message determines the FA from its
Traffic Engineering Database (TED) and tunnels the PATH message over
the FA. The FA tail-end on receiving the PATH message follows
procedures specified in previous sections. The FA tail-end sends a
RESV message to the FA head-end with a P2MP LSP label. The RESV
message is sent using the procedures in [LSP-HIER]. For example in
Figure 2, PE1 can setup a P2P LSP to P1 and use that as a FA. The
PATH messages for PE3 and PE4 can now be tunneled over the FA. Thus
P3 is not aware of the P2MP LSP and does not process the P2MP control
messages.
LSP hierearchy as described above has several advantages, some of
which are discussed below.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 12]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
10.1. Reduction in Control Plane Processing
Transit LSRs along a FA, being used by a P2MP LSP, do not process
control plane messages associated with the P2MP LSP. Infact they are
not aware of these messages as they are tunneled over the FA. This
reduces the amount of control plane processing required on these
transit LSRs. Hence the use of P2P LSPs as FAs can increase the
overall control plane scalability while setting up P2MP LSPs.
10.2. Support for LSRs that are not P2MP Capable
Its conceivable that some LSRs, in a network deploying P2MP MPLS TE,
may not be capable of P2MP MPLS. The use of FAs allows to build P2MP
LSPs in such an environment. As mentioned above transit LSRs along a
FA do not process control plane messages associated with a P2MP LSP.
Futhermore these LSRs also do not need to have P2MP MPLS data plane
capability as they only need to process MPLS data plane packets
belonging to the P2P LSP that is being used as a FA. Hence these LSRs
do not need to support P2MP MPLS. It is to be noted that such LSRs
can not act as branch points along the P2MP LSP.
11. IANA Considerations
This document requires the use of a RSVP-TE P2MP session object and a
RSVP-TE P2MP branch LSP sender template object. The C-Types for these
objects have to be assigned by IANA.
12. Security Considerations
This document does not introduce any new security issues. The
security issues identified in [RSVP-TE] are still relevant.
13. Acknowledgements
We would like to thank George Swallow for his contribution and
suggestions. Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger
and Nischal Sheth for their suggestions and comments. Thanks also to
Dino Farninacci for his comments.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 13]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
14. References
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001
[RFC] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997.
[GMPLS] Lou Berger, et al., "Generalized MPLS - Signaling Functional
Description", draft-ietf-mpls-generalized-signaling-08.txt,
April 2002
[G-RSVP] L. Berger, "Generalized MPLS Signaling - RSVP-TE Extensions",
draft-ietf-mpls-generalized-rsvp-te-09.txt, September 2002.
[RSVP-RR] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001.
[RSVP-FR] P. Pan, D. Gan, G. Swallow, J. P. Vasseur, D. Cooper,
A. Atlas, M. Jork, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt.
[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt.
Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Liming Wei
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: lwei@redback.com
draft-raggarwa-mpls-p2mp-te-00.txt [Page 14]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
George Apostolopoulos
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: georgeap@redback.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: kireeti@juniper.net
John Drake
Calient Networks
Email: jdrake@calient.net
IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 15]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt January 2004
Full Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 09:24:14 |