Internet DRAFT - draft-chung-mpls-rsvp-multicasting
draft-chung-mpls-rsvp-multicasting
Network Working Group Jong-Moon Chung
Internet Draft (Oklahoma State
Expiration Date: August 2002 University)
Mauricio A.
Subieta Benito
(Oklahoma State
University)
Harleen Chhabra
(Exxon Mobil)
Grace Yoona Cho
(Oklahoma State
University)
Pravin Rasiah
(Oklahoma State
University)
February 2002
RSVP-TE Extensions for MPLS Multicasting Services
draft-chung-mpls-rsvp-multicasting-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 addresses the required extensions to the Resource
Reservation Protocol (RSVP) to support MPLS network multicasting
functionalities. The concepts presented in this paper support the
delivery of multicasting traffic in accordance to the traffic
engineering (TE) parameters provided in the MPLS specifications. The
IP multicasting procedures based on the protocol procedural format
Jong-Moon Chung, et al. Page <1>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
of other multicasting protocols (e.g., PIM-DM, PIM-SM, DVMRP, MOSPF,
CBT, etc.) will be fully embedded into the RSVP-TE signaling
operations to enable all multicasting procedures to be conducted
through pure MPLS networking operations.
Table of Contents
1. Introduction................................................3
2. Extensions to RSVP for Multicasting in MPLS Networks........3
2.1. The MULTICASTING_SESSION and TREE objects...................3
2.1.1. LSP_IPv4 MULTICASTING_SESSION Object........................4
2.1.2. LSP_IPv6 MULTICASTING_SESSION Object........................4
2.1.3. TREE Object.................................................5
2.2. Extensions to RSVP: Join, Leave, McRecal, and Destroy
Messages....................................................6
2.2.1. Join message................................................6
2.2.2. Leave message (ResvTear message)............................7
2.2.3. Multicast Recalculation (McRecal) message...................7
2.2.4. Destroy message (PathTear message)..........................8
2.3. Multicasting LSP Tree Path and Resv Message Extensions......8
2.3.1. Multicasting Extensions to the Path Message (Msg type = 1)..8
2.3.2. Multicasting Extensions to the Resv Message (Msg type = 2)..8
2.4. Multicasting Extensions to the Hello Message................8
3. Construction of the Multicasting Distribution Tree using
RSVP-TE.....................................................9
3.1. Sender-Initiated Tree Calculation...........................9
3.2. Receiver-Initiated Tree Calculation........................11
3.3. Re-calculation Procedures..................................12
4. Conclusion.................................................13
5. References.................................................13
6. AuthorsÆ Addresses.........................................14
Abbreviations
CBT: Core Based Tree
CoS: Class of Service
DVMRP: Distance Vector Multicast Routing Protocol
FEC: Forwarding Equivalence Class
GoS: Grade of Service
MIDB: Multicasting Information Database
MOSPF: Multicast Open Shortest Path First
PIM-DM: Protocol Independent Multicasting-Dense Mode
PIM-SM: Protocol Independent Multicasting-Sparse Mode
QoS: Quality of Service
LSR-RP: Label Switching Router-Rendezvous Point
Jong-Moon Chung, et al. February 2002 Page <2>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
1. Introduction
Multi Protocol Label Switching (MPLS) networking provides an
underlying networking architecture to support various Traffic
Engineering (TE) and Quality of Service (QoS) features. However, the
current standards are not capable of providing MPLS based
multicasting traffic services, rather an IP controlled MPLS overlay
model is provisioned to conduct this task. The protocol extensions
to enable MPLS multicasting services proposed in this document
agrees with the fundamental framework proposed in [9]. The basic
concept is to enable MPLS to provide all functionalities and
services required for multicasting, where the addressing and
management topology of current IP multicasting users and groups will
be done by the Internet Group Management Protocol (IGMP), thereby
keeping the management and addressing the same as currently done in
IP, but enabling the TE advantages of MPLS to exist over the
multicasting network connections.
The proposed work in this document extends to the implementation of
MPLS multicast protocols and procedures based on the Resource
Reservation Protocol with Traffic Engineering (RSVP-TE) extensions
[1][2]. The extensions provided to RSVP for LSP tunnel applications
in RFC 3209 [1] are restricted to unicast label switched paths,
where multicast LSPs were left for further study. With this focus,
the technical approach proposed in this document is to enable RSVP-
TE with the full set of multicasting functionalities such that MPLS
networking is fully capable of multicasting control and services
rather than it being dependent on the IP over MPLS overlay model.
2. Extensions to RSVP for Multicasting in MPLS Networks
RSVP applies IP datagram forwarding as a transport mechanism [2].
The proposed extensions to RSVP enable the RSVP signaling mechanism
to establish, maintain, and terminate multicasting connections. This
can be accomplished by adding message types and new C-type
identifiers to the existing objects of the messages to establish
multicasting based operations using the objects of the RSVP-TE
messages.
2.1. The MULTICASTING_SESSION and TREE objects
The MULTICASTING_SESSION and the TREE objects explained in this
document can be used for the multicasting tree control procedures as
optional objects that are additional to the SESSION object (i.e.,
they do not replace the SESSION object). When a source that is
multicasting is associated with a particular multicast session, then
the RSVP-TE message format may include the MULTICASTING_SESSION and
TREE objects.
Jong-Moon Chung, et al. February 2002 Page <3>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
2.1.1. LSP_IPv4 MULTICASTING_SESSION Object
Class = MULTICASTING_SESSION, LSP IPv4_Multicast C-Type = 5
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 Multicasting Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Multicast ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Multicasting Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Multicasting Source Address
IPv4 address of the source node for multicasting tree.
Multicast ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
IPv4 Multicasting Group Address
A 32-bit IPv4 Multicasting group address used in the
multicasting session that remains constant over the life of the
multicasting tree connection.
2.1.2. LSP_IPv6 MULTICASTING_SESSION Object
Class = MULTICASTING_SESSION, LSP_Ipv6_Multicast C-Type = 6
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 Multicasting Source Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Multicast ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Multicasting Group Address |
+ +
| |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Multicasting Source Address
IPv6 address of the source node for multicasting tree.
Jong-Moon Chung, et al. February 2002 Page <4>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
Multicast ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
IPv6 Multicasting Group Address
A 16-byte IPv6 Multicasting group address used in the
multicasting session that remains constant over the life of the
multicasting tree connection.
The Multicast ID is used when there is a need to identify different
sessions of multicasting services over the same multicasting tree. If
there is no use for this field then it is set to all zeros.
2.1.3. TREE Object
The TREE object is a list of multicasting tree LSR-RP (Label
Switching Router-Rendezvous Point) addresses that are announced,
such that LSRs that are not part of the multicasting tree can
identify these LSR-RPs for future connection purposes to the
multicasting tree. A LSR-RP is any intermediate LSR that has two or
more branches that forward traffic or signaling downstream or
aggregate upstream. In addition, for the Join message sent from the
root LSR, the TREE object can be used to establish an explicit
traffic path when connecting to a new host. In this case, the TREE
object list of LSR-RPs will indicate this flow path, where the last
LSR-RP of the TREE object list will be the one to connect to the new
host. The TREE Class is 22. There are two C-Types defined.
Class = TREE, LSP_IPv4_TREE C-Type = 1
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 Multicasting LSR-RP Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Multicasting LSR-RP Address-N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Multicasting LSR-RP Address
A 32-bit IPv4 Multicasting LSR-Rendezvous Point address
Jong-Moon Chung, et al. February 2002 Page <5>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
Class = TREE, LSP_IPv6_TREE C-Type = 2
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 Multicasting LSR-RP Address-1 |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Multicasting LSR-RP Address-N |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Multicasting LSR-RP Address
A 16-byte IPv6 Multicasting LSR-Rendezvous Point address
2.2. Extensions to RSVP: Join, Leave, McRecal, and Destroy Messages
In order to accommodate the proposed RSVP-TE for multicasting
capabilities, four RSVP-TE messages are defined: Join, Leave,
McRecal, and Destroy.
2.2.1. Join message
We assume that the mechanisms that provide authentication and
authorization services are provided for the MPLS network, and that
the verification takes place for every node that requests
multicasting traffic.
When a new host wants to join an existing multicast tree, a Join
message will be issued by the new host thereby making a request to
join the multicasting tree. In the case where a non-connected label
switching router (LSR) is making this request, the LSR will send a
Join message to a multicasting LSR of the multicasting tree
requesting for a connection. Following this, a Join message will be
sent from that multicasting LSR to the root LSR of the multicasting
tree requesting a connection and to update the multicasting
information database (MIDB) with this request. This Join message may
trigger a recalculation of the tree for connection updates. In the
RSVP common header, the message type (Msg type) 8 is assigned to
indicate the Join message (Msg Type = 8).
Jong-Moon Chung, et al. February 2002 Page <6>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
The format of the Join message (Msg type = 8) is as follows:
<Join Message>:: = <Common Header> [<INTEGRITY>]
<MULTICASTING_SESSION>[<TREE>]
<RSVP_HOP>
[<TIME_VALUES>]
[<EXPLICIT_ROUTE>]
[<SESSION_ATTRIBUTE>]
[<POLICY_DATA>...]
[<sender descriptor>]
The MULTICASTING_SESSION object of the Join message will include the
information of the multicasting tree.
2.2.2. Leave message (ResvTear message)
A leaf LSR may initiate a Leave message when it does not have any
more hosts actively participating in the multicast session. The
Leave message used in multicasting is conducted by the ResvTear
message (Msg Type = 6 [2]) that is sent to the upstream LSR-RP,
which contains the MULTICASTING_SESSION object information. If the
LSR-RP sees that all attached multicasting users are not in service
anymore, then the LSR-RP will send a ResvTear message to the
upstream LSR requesting a disconnection from the multicasting tree.
In this fashion, the Leave functionality will enable parts of the
tree that are not used to disconnect itself in modular units.
2.2.3. Multicast Recalculation (McRecal) message
The McRecal message is used to inform the root LSR that it has to
recalculate the multicast tree for that multicasting group. It also
carries the updated information downstream to keep the MIDB of the
intermediate nodes current. The McRecal message is assigned Msg type
= 9.
A McRecal message must be routed like the corresponding Resv message
or a ResvTear message, and its IP destination address will be the
multicast address of the previous hop.
The format of the McRecal message (Msg type = 9) is as follows:
<McRecal Message>::= <Common Header> [ <INTEGRITY> ]
<MULTICASTING_SESSION> [<TREE>]
[<RSVP_HOP>]
[<TIME_VALUES>]
[<EXPLICIT_ROUTE>]
[<SESSION_ATTRIBUTE>]
[<POLICY_DATA>...]
[<sender descriptor>]
Jong-Moon Chung, et al. February 2002 Page <7>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
2.2.4. Destroy message (PathTear message)
The root initiates the Destroy function for a Multicast tree when it
wants to terminate a multicast session. The destroy function is
conducted through the PathTear message (Msg Type = 5 [2]), which is
sent from the root to all its downstream LSRs. The PathTear message
that is inherent in RSVP removes all the entries in the LSP as well
as all reservations.
2.3. Multicasting LSP Tree Path and Resv Message Extensions
In both the Path and Resv messages the SESSION objects can be used
with new C-Type assignments to indicate multicasting applications.
2.3.1. Multicasting Extensions to the Path Message (Msg type = 1)
In the Path message, the MULTICASTING_SESSION object provides
necessary information that should be included in addition to the
SESSION object. The MULTICASTING_SESSION object can be considered as
an optional object according to the needs of the multicasting
applications.
The Path message originates from the LSR-RP to the LSR that desires
to join the multicasting tree. The MULTICASTING_SESSION object will
enable LSRs that are not part of the multicasting tree to know of
the multicasting source and group information.
2.3.2. Multicasting Extensions to the Resv Message (Msg type = 2)
The Resv message is also extended with the MULTICASTING_SESSION and
TREE objects that can be treated as optional objects that are
additional to the SESSION object.
The MULTICASTING_SESSION and TREE objects used in the Resv message
are specified in Section 2.1.
2.4. Multicasting Extensions to the Hello Message
The RSVP Hello extension of RFC 3209 enables RSVP nodes to detect
when a neighboring node is not reachable. The HELLO mechanism is
intended for use between immediate neighbors, and therefore, a Hello
message and a Hello Acknowledgement message are exchanged between
two RSVP neighbors. The Hello message has a Msg Type of 20 [1]. The
extensions to the Hello message format for multicasting applications
are as follows:
<Hello Message>::= <Common Header> [<INTEGRITY>]
<HELLO>
[<MULTICASTING_SESSION>][<TREE>]
The MULTICASTING_SESSION object will enable LSRs that are not part
of the multicasting tree to know of the multicasting source and
group information. The TREE object contains a list of LSR-RPs. It
Jong-Moon Chung, et al. February 2002 Page <8>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
allows intermediate LSRs to identify the LSR-RPs for future
connections to the multicasting tree.
3. Construction of the Multicasting Distribution Tree using RSVP-TE
The calculation and construction of the multicasting distribution
tree must be done in two different contexts: sender-initiated tree
calculation, and receiver-initiated tree calculation. Sender-
initiated construction occurs when a new source of multicasting
traffic starts delivering traffic to all the members of a group,
which is known as a traffic-driven scheme. The receiver-initiated
calculation becomes useful when a new member of a group wants to
start receiving traffic, following a request-driven scheme.
The protocol fields that trigger the multicasting operations of
RSVP-TE as well as the procedures for creating the multicasting
trees, which have not been detailed in previous works, are provided
here. In addition, this document enables the multicasting functions
of RSVP-TE to be independent of traditional IP-based multicast
routing protocols, such as MDVMRP, MOSPF, PIM, etc. However, IGMP
will be used to provide the mechanism for establishing and
maintaining multicasting group memberships.
The TE parameters used in MPLS can provide DiffServ [4] and flexible
QoS features in the multicasting tree calculations. In order to
include the TE parameters as the main constraints for the tree
calculation, a set of extensions can be added to the traditional
routing calculation algorithms, such as the distance vector (DV) or
the link state (LS) algorithms. Furthermore, based on the current
backbone network layout and the topology of how the backbone
networks are administered by carrier companies, enough flexibility
at calculating the distribution trees has to be given. For this
purpose three different tree construction mechanisms can be
considered:
1. Tree construction by means of source controlled routing,
2. Tree calculation by means of using traditional algorithms such
as the DV or LS algorithms that are solely based on distance
oriented metric values, and
3. Tree calculation by means of enhanced versions of the DV or LS
algorithms that employ both TE parameters and distance oriented
cost values as metric values in the tree calculations.
In the following subsections, it is assumed that every LSR knows its
neighboring LSRs due to an execution of the RSVP-TE Hello message
procedures.
3.1. Sender-Initiated Tree Calculation
The calculation and construction of the tree should be performed
based on the LSRs that have active members (hosts) that wish to
receive multicasting traffic. We assume that they have been either
identified in advance or they will be joining dynamically.
Jong-Moon Chung, et al. February 2002 Page <9>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
In order to properly calculate the tree, the first step is to find
out if there is an IGMP group definition table constructed. This
information is assumed to be found in every node in a Network
Management System (NMS) database with listings of the group
memberships, or in a LSR. With this information, the Multicasting
Information Database (MIDB) is created with the purpose of keeping
track of all multicasting sources, distribution groups, and
destinations. In addition, the MIDB allows the multicast information
to be decentralized, making it more effective for dynamic group
membership control. If this information is not available, the RSVP-
TE Hello extensions mechanism with multicasting extensions can be
used to provide information to the MIDB.
With the information contained in the MIDB, the calculation for the
tree can be done quickly based on one of the methods described
above. Once the tree is calculated, the Path messages are generated
with the required session object (containing the source and group IP
multicasting addresses) along with the other necessary object field
information. Once all the messages have been delivered, and all the
reservations are defined, the multicast traffic can be delivered to
all the predefined nodes.
Distribution calculation based on MIDB information
+-----------+
| MIDB |
+-----+-----+
(3)Multicasting | |(1)Multicasting Tree |(2)Path message
Traffic | V Database Information| sent to all LSRs
+-----------+ --> +-----+-----+ V of the tree.
| Source +-----+ Root LSR |
+-----------+ +-----+-----+
| |(4)Multicasting Traffic (5,6,7)
| V (5) (6)
+-----+-----+ --> +-----------+ --> +-----------+
| LSR +-----+ LSR +-----+ Receiver 1|
+-----+-----+ +-----------+ +-----------+
| |(5)
| V (6) (7)
+-----+-----+ --> +-----------+ --> +-----------+
| LSR +-----+ LSR +-----+ Receiver 2|
+-----------+ +-----------+ +-----------+
In Step (1) the information gathered in the MIDB is used by the root
LSR to construct the distribution tree. The root LSR will send out
Path messages to the LSRs of the multicasting tree to establish LSP
connection (step (2)). This will be confirmed by Resv massages at
each link of the multicasting tree (not shown in the figure). After
the tree connection is completed the source starts multicasting
traffic through the root LSR to the LSRs in the multicasting tree
composed by Steps (3) through (7).
Jong-Moon Chung, et al. February 2002 Page <10>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
3.2. Receiver-Initiated Tree Calculation
A multicasting distribution tree is not static; hence, mechanisms
that allow dynamic calculation of the tree have to be defined. In
order to recalculate the tree, a node has to issue a Join, Leave, or
McRecal message. These messages have been defined in Section 2.2.
The receiver-initiated tree is based on a predefined source already
generating multicast content, and the information contained within
the MIDB.
1. When a node wants to request a multicasting tree connection,
the node will send a RSVP-TE Join message to a LSR-RP of the
multicasting tree.
2. This LSR-RP of the multicasting tree will then send a Join
message to the root LSR. This Join request will be checked
for multicasting tree connection permission. If permission is
granted, a recalculation of the tree may occur if necessary.
In this case, a McRecal message will be issued for the
recalculation of the multicasting tree.
3. If a multicasting tree recalculation has been requested, an
update to the label mapping table of each LSR of the
multicasting tree will be conducted. The update procedure
refreshes the interfaces in which each message is received
and the interfaces through which each message is forwarded.
4. The multicasting root LSR will issue a Join message to the
node that is requesting connection to the multicasting tree
through the LSR-RP that the root LSR decides to use for this
connection. This LSR-RP will issue a Path message to the new
host for connection establishment to the tree.
5. If the procedure is not successful, the new receiver that was
making the Join message request will wait for an arbitrary
timeout and retries until it is able to obtain a multicasting
link connection
Receiver-initiated tree calculation
+---------+ +-----------+
| Source +---+ Root LSR |
+---------+ +-----+-----+
| | ^ (2)Join
| |(3) | message (1)Join message
| V Join +---- <-------
+-----+-----+ +-----------+ +------------+
| LSR-RP +-----+ LSR-RP +-----+New Receiver|
+-----+-----+ +-----------+ +------------+
| ------> ------->
| (4)Join message (5)Path
| <-------
| (6)Resv
|
+-----+-----+ +-----------+
| LSR +-----+ LSR |
+-----------+ +-----------+
Jong-Moon Chung, et al. February 2002 Page <11>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
In the figure above, step (1) shows the Join message indicating the
new receiverÆs intention to receive multicasting traffic. Step (2)
shows the Join message generated from the LSR-RP that received the
Join message requesting the root LSR to establish a multicasting
connection. This in turn triggers the recalculation of the
multicasting tree. Assuming that permission has been granted by the
root LSR, steps (3) and (4) show a Join message issued by the root
LSR which will contain a TREE object. The root LSR will assign one
of the neighboring LSR-RP to the host to become its connecting LSR.
This LSR-RP will receive the Join message sent from the root LSR,
and the Join message will be converted to a Path message to enable a
LSP connection to the multicasting tree (step (5)). In step (5), a
specific label may be requested to the down stream new receiver such
that all outgoing multicasting connections from the LSR-RP may use
the same label [2]. Step (6) shows the Resv message that will
include the label to be used.
3.3. Re-calculation Procedures
As mentioned before, a multicasting tree is not normally static,
either because new nodes are joining or because nodes leave the
tree. When a LSR does not have any more multicasting receivers, it
will issue a RSVP-TE Leave message, which will be sent to the
upstream LSR in order to stop the multicast traffic. The upstream
LSRs will perform the following activities:
1. If the LSR that is leaving is not the last LSR within the tree,
then the upstream LSR will erase the label mapping entry for
the downstream LSR, and it will issue a McRecal message to the
root LSR such that the root LSR can recalculate the tree should
it be necessary. Otherwise, the root LSR will use this
information to request an update of the label mapping tables of
the LSRs along the multicasting tree. The information in the
MIDB will also be updated.
2. If a tree recalculation is conducted, the root LSR will trigger
a re-calculation procedure via a McRecal message so all the
LSRs can use the updated information in the MIDB.
3. If the LSR that is leaving is the last leaf LSR on the
multicasting tree, then the upstream LSR will in turn issue a
RSVP-TE Leave message. The MIDB table will then be updated. The
root LSR in turn (after receiving the message and recalculating
the tree) will trigger a recalculation procedure via a McRecal
message so all the nodes can use the updated information in the
MIDB.
4. If the leaving LSR is the last one connected to the root LSR
(that is, the root LSR will be the last node on the tree), then
the Leave message procedures will be performed. A Destroy
procedure of the tree will not be performed. The tree will be
kept alive and the tree will be recalculated and rebuilt when
new hosts request connection to the tree.
Jong-Moon Chung, et al. February 2002 Page <12>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
5. In the event that the source has no more multicast content to
multicast, the root LSR will issue a RSVP-TE Destroy message
that will notify all the LSRs in the tree that the label
mappings have to be released and all the multicasting traffic
forwarding should be stopped. This will also trigger a purge
procedure within the MIDB, clearing all the entries for the
specific multicasting group.
4. Conclusion
The extensions proposed to RSVP-TE of this document deliver the
basic configuration and functionality required to support
multicasting for MPLS networking applications. By establishing Join,
McRecal, Leave, and Destroy messages, a multicasting distribution
tree that is conformant with the constraints defined by the MPLS TE
parameters can be created through RSVP-TE signaling. Furthermore, by
combining the multicasting extensions for RSVP-TE with the IGMP
features for multicasting group database control and the Hello
message with the MIDB extensions a set of operational procedures
have been developed for the dynamic management of multicasting
trees. This conceptualization allows all traffic engineering
features of MPLS networking to be flexibly provided within the
multicasting services in a very efficient, scalable, and
straightforward fashion.
5. References
[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
Swallow, G., ææRSVP-TE: Extensions to RSVP for LSP Tunnels,ÆÆ RFC
3209, The Internet Society, Dec. 2001.
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification," RFC 2205, The Internet Society, Sept. 1997.
[3] Chung, J.-M., (Invited Paper) ææAnalysis of MPLS Traffic
Engineering,ÆÆ in Proc. IEEE Midwest Symposium on Circuits and
Systems 2000 (MWSCASÆ00), East Lansing, Michigan, U.S.A., Aug.
8-11, 2000.
[4] Chung, J.-M., Marroun, E., Sandhu, H., and Kim, S.-C., ææVoIP
over MPLS Networking Requirements,ÆÆ in Proc. IEEE International
Conference on Networking 2001 (ICNÆ01), Colmar, France, July 9-
13, 2001.
[5] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y.,
and Rasiah, P., ææLDP Extensions for MPLS Multicasting Services,ÆÆ
submitted, IEEE Networks.
[6] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y.,
and Rasiah, P., ææRSVP Extensions for MPLS Multicasting
Services,ÆÆ submitted, IEEE J. Select. Areas in Commun.
[7] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y.,
and Rasiah, P., ææLDP Extensions for MPLS Multicasting Services,ÆÆ
work in progress, Internet Draft, Internet Engineering Task
Force, The Internet Society.
[8] Miller, K. C., Multicast Networking and Applications, Addison-
Wesley, 1999.
Jong-Moon Chung, et al. February 2002 Page <13>
Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002
[9] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., and
Ansari, F., ææFramework for IP Multicast in MPLS,ÆÆ work in
progress, Internet Draft, Internet Engineering Task Force, The
Internet Society.
[10] Rosen, E. and Viswanathan, A., ææMultiprotocol Label Switching
Architecture,ÆÆ RFC 3031, The Internet Society, Jan. 2001.
[11] Stallings, W., High-Speed Networks TCP/IP and ATM Design
Principles. New Jersey: Prentice Hall, 1998.
[12] Whitmann, R. and Zitterbart, M., Multicasting Communication
Protocols and Applications. Morgan Kaufman Publishers, 1999.
[13] Williamson, B., Developing Multicasting Networks. Vol. I, Cisco
Press, 2000.
6. AuthorsÆ Addresses
Jong-Moon Chung
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-9924
Email: jchung_osu@lycos.com
Mauricio A. Subieta Benito
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-5215
Email: maurici@okstate.edu
Harleen Chhabra
Exxon Mobil
P.O. Box 4449
Houston, TX 77210-4449
Phone: (713)431-4106
Email: Harleen.Chhabra@exxonmobil.com
Grace Yoona Cho
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-5215
Email: chog@okstate.edu
Pravin Rasiah
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-2662
Email: pravinras10@lycos.com
Jong-Moon Chung, et al. February 2002 Page <14>
