One document matched: draft-raggarwa-mpls-p2mp-te-00.txt
Network Working Group Rahul Aggarwal
Internet Draft Liming Wei
Expiration Date: December 2003 George Apostolopoulos
Redback Networks
Kireeti Kompella
Juniper Networks
May, 2003.
Establishing Point to Multipoint
MPLS TE LSPs
draft-raggarwa-mpls-p2mp-te-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026, except that the right to
produce derivative works is not granted.
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.
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.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 1]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
Table of Contents
1 Introduction........................................ 2
2 Terminology......................................... 2
3 Problem Statement................................... 3
4 Mechanism........................................... 3
4.1 Spe Initiated P2P LSPs.............................. 4
4.2 P2MP LSP Session Object............................. 5
4.2.1 P2MP IPv4 LSP Session Object........................ 5
4.2.2 P2MP IPv6 LSP Session Object........................ 5
4.3 Example............................................. 6
4.3.1 Spe Initiated P2P LSPs.............................. 7
5 Rpe Discovery....................................... 7
6 Label Allocation on LANs with Multiple Downstream Nodes 7
7 Signaling Considerations............................ 8
8 Path Computation.................................... 8
9 Make-before-break and Fast Reroute.................. 8
9.1 Make-before-break................................... 8
9.2 Fast Reroute........................................ 9
10 IANA Considerations................................. 9
11 Security Considerations............................. 9
12 Intellectual Property Considerations................ 9
13 Acknowledgements.................................... 9
14 References.......................................... 9
15 Author Information.................................. 10
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.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 2]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
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.
3. Problem Statement
Source 1 (S1)
|
PE1
| |
| |
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
LSPs are initiated by the Spe. Hence its 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.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 3]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
Section 4.1 describes the steps as per this solution for achieving the
objectives outlined in section 3 when the P2P LSPs are Spe initiated.
It may be possible to have a mechanism where the P2P LSPs are Rpe
initiated. Such a mechanism is for further study.
4.1. Spe Initiated P2P LSPs
In this case the Spe is aware of all the Rpes interested in a given
Pid. How the Spe discovers this is application dependent and should
be specified in the application specific documents.
a) The Spe initiates the set up of a RSVP-TE P2P LSP to each Rpe for
a given Pid. Each P2P LSP is associated with the Pid. Hence it can
merge with other P2P LSPs to form a P2MP LSP. A new P2MP session
object is introduced for this purpose. The P2P LSP can be signaled
with shared semantics. Hence another P2P 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. The PATH message for
each P2P TE 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. This label is the "multicast label" if that node is
merging multiple RESV messages into one when sending the RESV
upstream. This will happen if each of the RESVs, for a given
session, received from downstream are using the same interface to
reach the upstream next hop. 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 set
up of a P2MP LSP from the Spe to the Rpes.
It is to be noted that RSVP semantics preserve each record route
object (RRO) associated with individual RESV messages when these
RESV messages are merged as described in (d) above. The flow
descriptor in the merged RESV messages contains the RRO list for SE
style reservation.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 4]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
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 cleaner and may be
easier for an implementation to associate the semantics for
multicast with a new session object. This new session object format is
the same as the existing session object with a new object type and
different semantics.
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 have to ensure
that this address is not used as the destination address. Infact
the destination address will have to be determined from the
explicit route.
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.
4.2.2. P2MP IPv6 LSP Session Object
Class = SESSION, LSP_P2MP_TUNNEL_IPv6 C-Type = TBD
draft-raggarwa-mpls-p2mp-te-00.txt [Page 5]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Spe Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Spe Address
IPv4 address of the Spe. An implementation may have to ensure
that this address is not used as the destination address. Infact
the destination address will have to be determined from the
explicit route.
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.
4.3. Example
Source 1 (S1)
|
PE1
| |
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.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 6]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
4.3.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 P2P 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 a RESV message to PE1.
It also creates a multicast label mapping of (L1 -> {L3, L4}).
f) PE1 also receives a RESV from P2 with a label of L2.
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
It is desirable on a LAN to use the same label for sending a packet
to multiple nodes belonging to the same P2MP LSP. As a result only
one copy of a packet needs to be transimitted by a sender on a LAN.
Achieving this requires certain modifications to the label allocation
procedure on a LAN. For Spe initiated P2MP LSP, all routers on a LAN
will snoop P2MP RESV messages. Hence the router alert option will be
set on P2MP RESV messages sent on a LAN. When a router on a LAN
'snoops' RESV messages from other routers, it should use the label
advertised in the snooped RESV, for its own RESV, if the following
conditions are met:
a) The snooped RESV belongs to the same session AND
b) The snooped RESV's source address is lower than the source address
of the RESV this router is originating AND
c) The sooped RESV's next-hop is same as the next-hop to which this
router is sending the RESV
When multiple routers send RESVs at about the same time, the upstream
router on the LAN will treat these as multiple P2P LSPs for a transient
duration. Eventually all the routers will converge to announcing the
same label and the upstream router will send out only one packet.
Procedures in [RSVP-RR] can be used to ensure reliable delivery of
RESV messages.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 7]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
Partitioning the label space amongst routers on a LAN is another
potential means of achieving the above. This approach will be discussed
in detail in a later revision.
7. Signaling Considerations
As mentioned earlier, in this approach, individual P2P LSPs merge to
form a P2MP LSP. A separate PATH message, with an explicit route object,
is sent for each P2P 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. It does increase the number of
PATH messages sent. RSVP refresh reduction [RSVP-RR] can be used to
reduce this overhead.
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 P2P 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. In the following discussion a P2P LSP refers to the
constituent P2P LSP of a P2MP LSP as described in this document.
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 P2P LSPs
that need re-routing are signaled with a different LSP ID and
follow the normal RSVP-TE make-before-break procedure. Infact the
re-optimization can be triggerred only for a specific P2P LSP.
2. A link failure in the network. In this case all the P2P LSPs that
are effected by the link failure are re-routed. Local repair is
initiated to protect the constituent P2P LSPs.
The granularity of the re-route operation is an individual constituent
P2P LSP. As a result the existing make-before-break procedures don't
change and the re-route can be done quite flexibly.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 8]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
9.2. Fast Reroute
[RSVP-FR] extensions can be used to perform fast reroute for the
mechanism described in this document. Details will be specified in a
later revision.
10. IANA Considerations
This document requires the use of a RSVP-TE P2MP session object. The
C-Types for this object have to be assigned by IANA.
11. Security Considerations
This document does not introduce any new security issues. The security
issues identified in [RSVP-TE] are still relevant.
12. Intellectual Property Considerations
Redback Networks, Inc. may seek patent protection on some of the
technology described in this Internet-Draft. If technology in this
document is adopted as a standard, Redback Networks agrees to
license, on reasonable and non-discriminatory terms, any patent
rights it obtains covering such technology to the extent necessary to
comply with the standard.
13. Acknowledgements
Many thanks to Yakov Rekhter and Dino Farninacci for their comments.
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.
draft-raggarwa-mpls-p2mp-te-00.txt [Page 9]
Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003
[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.
15. Author Information
Rahul Aggarwal
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: rahul@redback.com
Liming Wei
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: lwei@redback.com
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
kireeti@juniper.net
draft-raggarwa-mpls-p2mp-te-00.txt [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 09:32:08 |