One document matched: draft-raggarwa-pim-sm-mpls-te-00.txt
Network Working Group Rahul Aggarwal
Internet Draft Tom Pusateri
Expiration Date: March 2004 Juniper Networks
Dino Farinacci
Procket Networks
Liming Wei
Redback Networks
IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core
draft-raggarwa-pim-sm-mpls-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.
Abstract
This document describes procedures for IP multicast over a MPLS
Traffic Engineered (TE) core. The defined procedures apply when the
Provider Edge (PE) routers are running PIM-SM to exchange multicast
routing information with the Customer Edge (CE) routers. Point to
multipoint (P2MP) MPLS TE LSPs are used in the network core. The
procedures described make use of the PIM-SM remote neighbor
extensions described in [PIM-SM-REMOTE].
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 1]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
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].
1. Introduction
This document describes procedures for IP multicast over a MPLS TE
core. It addresses the case where MPLS TE is used in the network core
and the edge PE routers are participating in multicast routing with
CE routers or routers in other network domains. The following figure
shows a sample topology:
Multicast Source 1 (S1) (G1, G2, G3)
|
Spe1
| |
| |
R2----Rpe2--P1 P2---Rpe1--(R1) (G1)
(G2, G3) |
Rpe3----R3 (G2, G3)
|
|
R4 (G1)
Figure 1.
A source-PE (Spe) is the PE that is receiving traffic from the
multicast traffic source. The multicast traffic source may be one or
more hops away. A receiver-PE (Rpe) is the PE that is delivering
multicast traffic to one or more receivers. The receivers may be one
or more than one hop away.
In Figure 1 Spe1 is the source-PE. Rpe1, Rpe2 and Rpe3 are receiver-
PEs. Spe1, Rpe1, Rpe2 and Rpe3 are the edge routers and are
participating in multicast routing with S1, R1, R2, R3 and R4. S1 is
the multicast source that is sending traffic for groups G1, G2 and
G3. R1, R2, R3 and R4 are multicast receivers. R1 is listening to
G1, R2 to G2 and G3, R3 to G2 and G3 and R4 to G1. P1 and P2 are the
core routers and are participating in MPLS TE along with the edge
routers.
In such a scenario it may not be desirable to run PIM-SM in the
network core i.e on P1 and P2 in Figure 1. This may be because:
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 2]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
a) It is desired to keep core routers free of multicast routing
state.
b) It is desired to have a BGP free core. BGP is needed in the
core to distribute unicast routes for multicast RPF used by PIM-SM.
This is no longer the case if PIM-SM is not used in the network core.
Thus if the core is BGP free for unicast routing (e.g. RSVP-TE is
used in the core), not running PIM-SM in the core ensures that a
provider can truly have a BGP free core.
c) The multicast application that the PE routers are participating
in makes it necessary to use TE in the core for multicast traffic
[P2MP-MPLS-TE-REQ].
d) PIM-SM control traffic may originate from outside the provider
domain. In this case it may be desirable to keep the PIM-SM control
traffic out of the network core.
The procedures described in this document enable a provider to offer
IP multicast services and at the same time have a multicast routing
(i.e. PIM-SM) free core. The mechanism described depends on the
presence of P2MP MPLS TE LSPs [P2MP-MPLS-TE-REQ, P2MP-RSVP-TE] in the
network core. The rest of this document uses the term P2MP LSP to
refer to a P2MP MPLS TE LSP. Thus in Figure 1 there may be a P2MP
LSP from Spe1 with Rpe1, Rpe2, Rpe3 as the endpoints. P2MP MPLS TE
technology is being developed in the MPLS WG. [P2MP-RSVP-TE]
describes one mechanism for setting up P2MP LSPs. However the
procedures described in this document are independent of the
mechanism used for setting up the P2MP LSP.
This document describes:
a) Exchange of multicast routing information between the edge
routers
b) Discovery of the P2MP LSP endpoints by a Spe. Thus with respect
to Figure 1, discovery of Rpe1, Rpe2 and Rpe3 as endpoints of a
particular P2MP LSP, by Spe1.
c) Association of the multicast routing state with a P2MP LSP.
This pertains to associating multicast routing state that Spe1 learns
from Rpe1, Rpe2 and Rpe3 with the relevant P2MP LSP.
d) The forwarding state at the Spe and the Rpe to enable IP
multicast over a P2MP LSP.
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 3]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
2. PIM-SM Control State Exchange Between Edge Routers
As mentioned in the previous section, the network core is PIM-SM
free. However the edge PE routers are running PIM-SM towards the CEs
or other network domains. Thus they need to exchange PIM-SM routing
information. This is accomplished by using PIM-SM remote neighbors
as described in [PIM-SM-REMOTE]. The reception of a PIM-SM
Join/Prune for a particular multicast source address (S) at a Rpe, is
followed by resolving S onto the BGP next-hop that is advertising S.
The BGP next-hop for reaching S is the Spe. The resolution of a PIM-
SM Join/Prune onto a Spe results in the Rpe initiating a remote
neighbor adjacency with the Spe. This is followed by the Rpe sending
the PIM-SM Join/Prune to the Spe.
For instance in Figure 1, if Rpe1 receives a PIM-SM Join/Prune
message from R1, for S1 as the source, it has to propagate the Join
to Spe1. Rpe1 learns the route to reach S1 from Spe1. Hence when it
receives a PIM-SM Join for S1, it determines Spe1 as the next-hop for
reaching S1. Rpe1 then establishes a remote neighbor adjacency with
Spe1. It then sends the Join/Prune message to Spe1.
It is to be noted that the Rpes may be running IGMP towards the
receivers. In that case if the IGMP joins are source specific, the
Rpe can send PIM-SM Joins as described above to the Spe. Else PIM-SM
Joins have to be sent to the RP.
3. P2MP LSP Endpoint Discovery
As described above [PIM-SM-REMOTE] procedures are used to propagate
PIM-SM Join/Prune messages from a Rpe to the Spe. The receipt of a
PIM-SM Join message from a Rpe allows the Spe to treat the Rpe as a
P2MP LSP leaf. There may be various ways to associate the Join
message with a particular P2MP LSP. This is discussed further in the
next section. Once the Join message is associated with a P2MP LSP,
Spe initiates the setup of the P2MP LSP with the Rpe as the endpoint,
if the P2MP LSP doesn't already exist. If the P2MP LSP exists, but
the Rpe is not one of the existing leaves, Spe adds the Rpe as a new
leaf to the existing P2MP LSP. If the P2MP LSP exists and the Rpe is
one of the existing leaves, Spe leaves the existing P2MP LSP
unchanged.
Let us consider an example with respect to Figure 1.
a) R4 sends a PIM-SM Join for (S1, G1) to Rpe3.
b) Rpe3 determines Spe1 as the next-hop for reaching S1. It
establishes a remote neighbor adjacency with Spe1 and sends the
directed Join to Spe1.
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 4]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
c) Spe1 decides to map (S1, G1) received from Rpe3 to P2MP-LSP1.
As described in the next section, the exact procedures for this
mapping are a matter local to Spe1. Initially, P2MP-LSP1 doesn't
exist, so Spe1 initiates the setup of P2MP-LSP1 with Rpe3 as a
destination.
d) R1 sends a Join for (S1, G1) to Rpe1.
e) Rpe1 follows [PIM-SM-REMOTE] procedures and sends the directed
Join to Spe1.
f) Spe1 maps (S1, G1) received from Rpe1 to P2MP-LSP1
g) Spe1 adds a new branch to P2MP-LSP1 with Rpe1 as a destination.
If the Spe receives a Prune from a Rpe, it first associates the Prune
with a P2MP LSP. If the Spe has no other Join state that would keep
Rpe on the P2MP LSP, it can remove Rpe from the LSP. If this was the
last Rpe interested in the P2MP LSP, this will result in tear down of
the P2MP LSP.
4. Mapping IP Multicast Traffic to a P2MP LSP
The Spe on receiving a Join message for a particular (S, G) or (*, G)
associates this Join message with a particular P2MP LSP. This in turn
results in creating a multicast forwarding entry for that source and
group with the P2MP LSP as an outgoing interface. As a result the IP
multicast traffic for that source and group can be sent to the P2MP
LSP. The selection of the P2MP LSP for a particular source and group
is a decision that is local to the Spe. A few potential schemes for
selecting a P2MP LSP are outlined here:
a) The Spe may create only one P2MP LSP for all possible Rpes. In
this case each new Rpe is added as a leaf to that P2MP LSP. Clearly
this has the disadvantage of sending all the multicast traffic to all
the Rpes that are part of the P2MP LSP. Thus in Figure 1, Spe1 may
decide to map (S1, G1), (S1, G2) and (S1, G3) from all the Rpes to
the same P2MP-LSP. As a result Rpe1 will receive traffic for (S1, G2)
(S1, G3) and Rpe2 for (S1, G1), even though they do not have any
receivers interested in the same.
b) On the other extreme the Spe may be configured to create a
separate P2MP LSP for every multicast source and group. Hence a (S,
G) entry is mapped to the P2MP LSP corresponding to the multicast
source S and group, G. The number of P2MP LSPs in this case is equal
to the number of multicast source, group combinations. This has
scaling limitations. Thus in Figure 1, Spe1 may setup three P2MP
LSPs. One each for (S1, G1), (S1, G2) and (S1, G3).
c) The Spe may associate a set of (S, G) entries Ssg = {(S1, G1),
(S2, G2)... (Sn, Gn)} with the same P2MP LSP. The exact procedures
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 5]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
for doing this are outside the scope of this document. One example is
when all the Rpes that are part of the P2MP LSP have sent Join
messages for all the members of Ssg. Spe1, in Figure 1, may map (S1,
G1) to P2MP-LSP1 and {(S1, G2), (S1, G3)} to P2MP-LSP2. P2MP-LSP1
includes destinations Rpe1 and Rpe3. P2MP-LSP1 includes destinations
Rpe2 and Rpe3.
5. RPF Interface on a Rpe
A Rpe has to associate a particular P2MP LSP as the RPF interface for
a given (S, G) entry that the Rpe has propagated to a Spe. This P2MP
LSP must be the same as the P2MP LSP that is used by the Spe for
sending IP multicast traffic for that paricular (S, G) entry. As
described above the selection of a P2MP LSP for a (S, G) entry is Spe
driven. This implies that a Spe has to propagate the association
between a P2MP LSP and all the (S, G) entrires being mapped onto that
LSP, to all the Rpes that are part of that P2MP LSP.
This document introduces a new PIM-SM message, Join Acknowledge, for
this purpose. It also introduces the notion of "PIM-SM Route
Attributes" that can be used to associate common properties
associated with the Group Sets in a Join Acknowledge message. Thus a
Join Ack can be sent by the Spe to a particular Rpe and convey the
P2MP LSP identifier associated with the (S, G) entries, by encoding
it as a Route Attribute.
Once the Rpe receives the P2MP LSP association for a particular (S,
G) entry, it uses that P2MP LSP as the RPF interface for the (S, G)
entry. It is to be noted that the P2MP LSP interface will be inferred
based on the incoming MPLS label. Hence penultimate hop popping has
to be disabled for a P2MP LSP carrying IP multicast traffic.
5.1. Route Attribute
This document introduces the notion of a PIM-SM Route Attribute List.
This is a list of Route Attributes that can encoded in a PIM-SM
message. The intention is to associate the Group Sets in the message
with a set of Route Attributes. For solving the RPF problem which is
explained above, one of these Attributes can be used for mapping the
Group Sets carried in the Join Acknowledge message to a particular
P2MP LSP. It is envisioned that these Route Attributes can also be
more generally applicable.
A Route Attribute List contains a list of Route Attributes:
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
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 6]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Attribute 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Attribute n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
List Length is the total length in bytes of all the Route Attributes
in the list. A Route Attribute has a TLV style encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
Currently only one Route Attribute TLV is defined: "P2MP LSP
Attribute", with Type = 1. The length and value are set based on the
P2MP LSP Identifier as defined in [P2MP-RSVP-TE].
5.2. Join Acknowledge
This is a new PIM-SM message with Type=9. It is sent by the
destination of the Join message to the source of the Join message. It
carries attributes associated with the Group Sets that the
destination of the Join message wishes to convey to the source of the
Join message. Following is the format of the Join Acknowledge
message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 7]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
| Route Attribute List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hence to solve the RPF interface issue, the Spe sends a Join
Acknowledge to a particular Rpe. The Join Acknowledge carries the
P2MP LSP Attribute. This enables the Rpe to receive the P2MP
association for the Group Sets.
6. Security Considerations
Security considerations discussed in [PIM-SM] and [PIM-SM-REMOTE]
apply. Other security considerations are for further study.
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 8]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
7. Acknowledgments
We would like to thank Kireeti Kompella for his contribution and in
particular for his suggestions on determining the RPF interface at
the Rpe. We would also like to thank Ron Bonica for his input
regarding the problem and the solution presented in this draft.
8. References
[PIM-SM] PIM WG, B. Fenner, M. Handley, H. Holbrook, I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)",
draft-ietf-pim-sm-v2-new-08.txt.
[PIM-SM-REMOTE] R. Aggarwal, T. Pusateri,
"PIM-SM Extensions for Supporting Remote Neighbors",
draft-raggarwa-pim-sm-remote-nbr-00.txt
[P2MP-RSVP-TE] R. Aggarwal et. al., "Establishing Point to Multipoint
MPLS TE LSPs", draft-raggarwa-mpls-p2mp-te-00.txt
[P2MP-TE-REQ] S. Yasukawa et. al., "Requirements for
Point-to-Multipoint capability extension to MPLS",
draft-yasukawa-mpls-p2mp-requirement-00.txt
[RFC] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Tom Pusateri
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: pusateri@juniper.net
Dino Farinacci
Procket Networks
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 9]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
3850 North First Street
San Jose, CA, 95134
Email: dino@procket.com
Liming Wei
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: lwei@redback.com
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.
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
draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 10]
Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003
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-pim-sm-remote-nbr-00.txt [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 09:46:24 |