Internet DRAFT - draft-chung-mpls-ldp-multicasting
draft-chung-mpls-ldp-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
LDP Extensions for MPLS Multicasting Services
draft-chung-mpls-ldp-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 paper proposes the extensions necessary for the Label
Distribution Protocol (LDP) to support MPLS network multicasting
functionalities. The IP multicasting requirements based on the
protocol procedural format (e.g., PIM-DM, PIM-SM, DVMRP, MOSPF, CBT,
etc.) will be fully embedded into the LDP signaling procedures to
enable multicasting operations through pure MPLS networking
procedures alone.
Jong-Moon Chung, et al. Page <1>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
Table of Contents
1. Introduction................................................3
2. Extensions to LDP for Multicasting in MPLS Networks.........4
2.1. Multicasting Message........................................4
2.1.1. Join Command................................................6
2.1.2. Leave Command...............................................6
2.1.3. Destroy Command.............................................6
2.2. Hello Message Extensions....................................7
2.3. Notification Message Extensions.............................7
2.4. Multicast Extensions of the Label Request Message...........7
2.5. Multicast Extensions of Label Mapping Message...............8
2.6. MPLS Multicast Forwarding Table.............................8
3. Multicasting Tree Operations................................9
3.1. Joining Mechanisms..........................................9
3.2. Multicasting Tree Construction.............................12
3.2.1. Construction of a LDP Multicasting Distribution Tree.......12
3.2.2. Root-Initiated Tree Calculation............................13
3.2.2.1.Calculation based on IGMP information.....................13
3.2.3. Leaf-Initiated Tree Calculation............................14
3.2.4. Dynamic Updates to the Tree................................15
4. Conclusions................................................16
5. References.................................................16
6. AuthorsÆ Addresses.........................................17
Abbreviations
DS: Differentiated Services
DVMRP: Distance Vector Multicast Routing Protocol
FEC: Forwarding Equivalence Class
GoS: Grade of Service
IGMP: Internet Group Management Protocol
LDP: Label Distribution Protocol
LSP: Label Switching Path
LSR-RP: Label Switching Router-Rendezvous Point
MIDB: Multicast Information Database
MOSPF: Multicast Open Shortest Path First
MPLS: Multiprotocol Label Switching
PIM-DM: Protocol Independent Multicasting-Dense Mode
PIM-SM: Protocol Independent Multicasting-Sparse Mode
QoS: Quality of Service
RPF: Reverse Path Forwarding
Jong-Moon Chung, et al. February 2002 Page <2>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
1. Introduction
Multicasting can be viewed as a controlled or restricted application
of broadcasting, a point-to-multipoint mechanism that allows several
interested parties, namely hosts and/or routers to receive packets
of information at the same time. This process requires not only a
connection-oriented mechanism with high reliability and quality of
service (QoS) support, but also a method of seamlessly communicating
from one to many points.
In Multiprotocol Label Switching (MPLS) networks, a signaling
protocol that provides connection-oriented, reliable, differentiated
services, and QoS is the Label Distribution Protocol (LDP). LDP
sets up label-distributed paths to support data transfer in MPLS
networks. LDP is a hard-state, scalable, nonproprietary traffic
engineering signaling protocol that allows the creation, management,
and teardown of Label Switched Paths (LSPs) in MPLS networks [10].
RFC 3036 notes that LDP support for multicast is not specified and is to be
addressed in future studies [1]. Based on this, several extensions to the LDP
signaling protocol are proposed in this document to support
multicasting services. These extensions produce a mechanism for
creating root-initiated and leaf-initiated trees for multicasting
through LDP. The proposed work agrees with the framework concepts of
[13] and presents operational procedures of multicasting through
extensions to LDP. The basic concept is to enable MPLS networking
with all the 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)[8][9], thereby keeping the management and
addressing the same, but enabling the Traffic Engineering (TE)
advantages of MPLS to exist over the multicasting network
connections.
The protocol fields that trigger the multicasting operations of LDP
as well as the procedures for creating the multicasting trees, and a
means for incorporating tree calculations into LDP are provided in
this document. Additionally, this document enables the multicasting
functions of LDP to be independent of traditional IP-based multicast
routing protocols such as DVMRP, MOSPF, PIM, etc.
For the extensions to the LDP specifications defined in RFC 3036,
the common multicasting functions that the IP multicast routing
protocols offer, such as tree formations with Join, Leave, Destroy,
and RPF messages should directly be implemented in LDP to enable
MPLS based multicasting. This document also addresses the issues of
aggregating LSPs for multicasting, handling and storing multicasting
data in a decentralized fashion, piggybacking, and label allocation
[13].
Jong-Moon Chung, et al. February 2002 Page <3>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
2. Extensions to LDP for Multicasting in MPLS Networks
2.1. Multicasting Message
The Multicasting message is used to conduct a Join, Leave, or
Destroy command of the multicasting tree. When a leaf-initiated Join
operation must be performed, a Multicast message is sent (by means
of a unicast transmission) to a LSR of the existing multicast tree
to create a new LSP connection to the leaf. The Leave command is
issued by a LSR to its upstream LSR when it finds that no members
receiving multicasting traffic is connected to it. The Destroy
command is initiated when the source stops multicasting and it wants
to tear down the tree. The above commands (i.e., Join, Leave, and
Destroy) can be implemented by using the Multicast Message.
The Multicast message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Message Type: Multicasting| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicasting TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TVLs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields contained in the Multicast message are explained as
follows:
Message Type
This field indicates that this message type is the Multicasting
message. The coding for this message takes the standard
identification format as indicated in LDP. The specific
identification number is to be announced.
Message length
Indicates the length of the Multicast message.
Message ID
Indicates the identification of each message.
Multicasting TLV
The multicast command TLV includes three main command types, which
are Join (0x0001), Leave (0x0002), and Destroy (0x0003).
Jong-Moon Chung, et al. February 2002 Page <4>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
The Multicasting TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Multicasting | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Reserved | Multicast ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicasting IP Source address (4 or 16 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicasting IP Group address (4 or 16 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Multicasting TLV can be used in other messages when needed. The
fields contained in the Multicasting TLV message are explained as
follows:
V
Identifies the IP protocol version. A value of zero indicates IPv4
and value of one indicates IPv6.
Multicast ID
A 16-bit identifier used in the session that remains constant over
the life of the tunnel. This identifies different types of service
sessions that are used over the same multicasting tree.
Multicasting IP Source Address
IPv4 (4 bytes) or IPv6 (16 bytes) address of the source node of
the multicasting tree.
Multicasting IP Group Address
IPv4 (4 bytes) or IPv6 (16 bytes) multicasting group address used
in the session that remains constant over the life of a
multicasting tree connection.
The three command types that can be operated by the multicasting
message (Join, Leave, and Destroy commands) are explained below in
sections 2.1.1, 2.1.2, and 2.1.3.
The Tree TLV is used to provide a list of selected multicasting tree
Label Switching Router Rendezvous Point (LSR-RP) addresses that are
listed for identification purposes (as in the Hello messages) or for
selected path traversing (as in the Notification messages). In this
document, the LSR-RP is defined as a LSR that is functioning (or may
function) as a multicasting terminal to other LSRs or hosts that
will receive multicasting traffic through itself. A LSR-RP is any
intermediate LSR that has two or more branches that forward traffic
downstream or aggregate traffic upstream.
Jong-Moon Chung, et al. February 2002 Page <5>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
The Tree TLV can be used in other LDP messages when needed. The Tree
TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Tree | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Reserved | Multicast ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Multicasting LSR-RP Address-1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Multicasting LSR-RP Address-N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V
Identifies the IP protocol version. A value of zero indicates IPv4
and value of one indicates IPv6.
IP Multicasting LSR-RP Address
IPv4 (4 bytes) or IPv6 (16 bytes) address of the LSR-RPs of the
multicasting tree.
2.1.1. Join Command
The Join command is initiated when a LSR has identified a
multicasting group that it wants to join in order to receive group
specific multicasting data. The joining mechanism is reviewed in
detail in section 3.1.
2.1.2. Leave Command
The Leave command allows members of the multicast group to detach
themselves from the group, stopping all information from the group
to reach the pruned member. For example, a member may decide to stop
participating in the group. In this case, a Leave command must be
initiated by the receiving LSR to the upstream LSR of the
multicasting tree to indicate the end of its participation.
Correspondingly, the upstream LSR will send a Leave command to the
root LSR such that the Multicast Information Database (MIDB)
information can be updated.
2.1.3. Destroy Command
The Destroy command is used when the label switched path created for
the multicasting group is no longer needed. This may result due to
the source not having any more data to transmit to the multicasting
group members. When the destroy procedure takes place, all branches
within the multicast tree are torn down to end all data flow for the
Jong-Moon Chung, et al. February 2002 Page <6>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
entire group. The Destroy command is issued through the Multicasting
message.
As the multicasting group is no longer needed, the root LSR sends a
Multicasting message with a Destroy command indication to its
directly connected LSRs, which will be forwarded to other downstream
LSRs. The receiving LSRs will identify this command and will
disconnect from its upstream LSR through label release procedures
[1]. This procedure continues until the Destroy command reaches the
last LSR of the tree, which then disconnects from their upstream
LSRs.
2.2. Hello Message Extensions
The multicasting extensions to the Hello message include the
Multicasting TLV and the Tree TLV. The Multicasting TLV is an
optional TLV to the Hello message, which is used to inform the LSRs
of the multicasting source and group IP address of the multicasting
tree. The Tree TLV is also an optional TLV to the Hello message,
which provides a list of multicasting tree LSR-RP addresses that are
announced such that LSRs that are not part of the multicasting tree
can identify these LSR-RP addresses for future connection purposes.
2.3. Notification Message Extensions
In order to provide advisory information of a significant event to a
LDP peer node, a LSR will issue a Notification message [1]. For
example, the outcome of processing a LDP message or the state of the
LDP session is informed using the Notification message. The
Notification message contains a Status TLV that encodes the
information and, on an optional basis, additional TLVs that provide
more information about the condition of the network connection.
The multicasting extensions to the Notification message include the
Multicasting TLV and the Tree TLV. Based on applications of
multicasting, Join and Leave messages require the root LSR to
respond to their request with either permission for connection to
the multicasting tree or requesting procedures to disconnect using
label release procedures. The multicasting extensions to the
Notification message serves this purposes of communication between
the root LSR and the LSR-RP that needs to conduct the connection or
disconnection establishments to or from the multicasting tree.
2.4. Multicast Extensions of the Label Request Message
The message that allows the construction of the distribution tree is
the LDP Label Request message [1]. The extensions to the Label
Request message will include an optional Multicasting TLV for
multicasting applications of either responding to a Join command of
a multicasting message or when the multicasting tree wants a LSR to
join a multicasting tree.
Jong-Moon Chung, et al. February 2002 Page <7>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
2.5. Multicast Extensions of Label Mapping Message
The label mapping procedure operates as defined by [1] with the
option that there can be more than one outgoing label mapping for a
specific incoming interface. The format of the Label Mapping message
is also the same as defined in [1]. If necessary, a multicasting TLV
may be used as an option. More details of the Label Mapping message
are provided in the following sections.
2.6. MPLS Multicast Forwarding Table
All the multicasting enabled LSRs should at least maintain the
label-mapping forwarding table. The contents of the table are
explained below.
Interface IP
The IP address of the interface on which multicasting traffic for
a particular multicasting group has to be forwarded to.
Multicasting Group IP
Specifies the multicast address of all multicasting groups that
are being serviced by the LSR.
Input Label and Output Label
Labels assigned to the incoming and the outgoing interfaces,
respectively.
Status
Defines whether that particular entry in the forwarding table is
pruned or active.
The information included for the control of multicasting procedures
in the MPLS Multicast Forwarding table is similar to the information
maintained by the DVMRP Forwarding Table [17].
Jong-Moon Chung, et al. February 2002 Page <8>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
3. Multicasting Tree Operations
3.1. Joining Mechanisms
The Join command is initiated when a host wants to receive
multicasting traffic from the multicasting group. The LSR on whose
interface the host resides initiates the Join command.
There are three ways in which a host can join the multicasting
group:
1. Source initiated mechanism:
1.a. Creating a new multicasting tree: When the root LSR is
initially establishing the tree, a Label Request message
with the multicasting TLV is sent to all LSRs that the root
LSR wants to use in establishing the multicasting tree.
1.b. Adding on a LSR: The source initiated mechanism is
triggered when the multicasting tree wants to include a LSR
as a part of its multicasting tree. This provision has been
included such that the source can build on to the multicast
tree according to its necessity. The root LSR will send a
Notification message with multicasting extensions (i.e.,
Multicasting TLV and Tree TLV) that contain the information
regarding the LSR-RP that has to connect the new LSR on to
the tree. The LSR-RP will then send a Label Request message
to the new LSR, which will be responded by a Label Mapping
message. The procedures presented in sections 3.2.1, 3.2.2,
and 3.2.3 will complete the join process. (See steps 1
through 5 in the diagram below)
Jong-Moon Chung, et al. February 2002 Page <9>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
Source initiated mechanism
+-----------+ +-----------+
| Source +-----+ Root LSR +
+-----------+ +-----+-----+
|
------->+ | |
| | | (1) Notification message
| | |
| | V
| +-----+-----+ +-----------+ +-----------+
| | LSR-RP +------+ LSR +-----+ LSR |
| +-----+-----+ +-----------+ +-----------+
| |
| | |
| | |
| | |
| | V (2) Notification message
| | -------------->
| +-----+-----+ +-----------+ +-----------+
| | LSR-RP +------+ LSR-RP +-----+ LSR |
| +-----------+ +-----------+ +-----------+
| (3) Label Request Message
| <--------
| (4) Label Mapping Message
| -------->
V (5) Multicasting data
+------------------------------------------->
2. Control driven mechanism: We assume the presence of a root
LSR that has information about every multicast group and its
tree nodes. When a particular host requests for multicasting
traffic from a particular group, the host will send a Join
command request to the upstream LSR. The Join messageÆs
Multicasting TLV may have all zero entries to the
multicasting source or/and group address, which indicates
that this is a request for multicasting tree information.
Either the root LSR or a LSR that has information of the
multicasting tree will send back a Notification message
(with multicasting extensions) that contain the information
regarding nodes in the receiverÆs vicinity that are nodes of
the multicasting distribution tree for that particular
multicasting group IP address. The multicasting information
obtained is used in the Multicasting messages and the
Multicasting TLV. The receiving LSR will then issue a
Multicasting message with a Join command requesting
connection to the multicasting tree. The procedures
presented in sections 3.2.1, 3.2.2, and 3.2.3 will complete
the join process.
Jong-Moon Chung, et al. February 2002 Page <10>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
Control driven mechanism
(2a) Join command*
<--------+
+-----------+ +-----------+ |
| Source +-----+ Root LSR +-----------+ |
+-----------+ +-----+-----+ | |
---------+ (3)**| |(2b)Join Command*| | (1)Join Command
| V | <------ | | <-----
| +-----+-----+ +----+------+ +-----------+
| | LSR-RP +------+ LSR-RP +-----+ LSR 1 |
| +-----+-----+ +-----------+ +-----------+
| | ---------> (4) Notification message
| | (5) Label Request------->
| |
| | (6) Label Mapping<-------
V |
+---------|--------------------------------->
| (7) Multicasting Data
+-----+-----+ +-----------+ +-----------+
| LSR +-----+ LSR +-----+ LSR 2 |
+-----------+ +-----------+ +-----------+
* Either (2a) or (2b) will be used
** Notification Message
3. Flooding mechanism: If the LSR trying to connect to the
distribution tree has no information about the multicasting
LSRs around it, flooding can be used to spread the Join
command. The Join messageÆs Multicasting TLV may have all
zero entries in the multicasting source or/and group
address, which indicate that this is a request for
multicasting tree information. The flooding procedure takes
place under the traffic engineering requirements. The root
LSR then processes the request and sends back a Notification
message (with multicasting extensions) that contain the
information regarding nodes in the receiverÆs vicinity that
are nodes of the multicasting distribution tree for that
particular multicasting group IP address. The receiving LSR
will then issue a Multicasting message with a Join command
to those nodes. The procedures presented in sections 3.2.1,
3.2.2, and 3.2.3 will complete the join process.
The Label Request message and Join command must include the IP
multicasting group and source IP addresses using the Multicasting
TLV. If the Join command is passed on from one LSR to the next LSR
upstream, the IP address of the intermediate LSRs may be added on to
the TREE TLV such that the path in which the tree is being formed
can be identified at the root LSR.
Jong-Moon Chung, et al. February 2002 Page <11>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
Flooding mechanism
(2a) Join command*
<--------+
+-----------+ +-----------+ |
| Source +-----+ Root LSR +-----------+ |
+-----------+ +-----+-----+ | |
-------+ (3)**| |(2b)Join command*| | (1)Join command
| V | <------ | | <-----
| +-----+-----+ +----+------+ +-----------+
| | LSR-RP +------+ LSR-RP +-----+ LSR 1 |
| +-----+-----+ +-----------+ +-----------+
| | --------->(4)Notification message
| | (5) Label Request------->
V | (6) Label Mapping<-------
+---------|---------------------------------->
| (7) Multicasting Data
|
+-----+-----+ +-----------+ +-----------+
| LSR +-----+ LSR +-----+ LSR 2 |
+-----------+ +-----------+ +-----------+
* Flooding of both (2a) and (2b) will be used
** Notification Message
The Join command is sent on all the interfaces with traffic
parameters. If these traffic parameters cannot be met, then a
negotiation procedure of the traffic parameters takes place.
3.2. Multicasting Tree Construction
Based on the LDP specification of RFC 3209 [1], each LSR in the
network will announce and learn the presence of each other in the
network by using LDP Hello messages. The discovery procedures
provide a mechanism to enable LSRs to indicate their presence in a
network by sending a Hello message periodically [1]. This message is
transmitted to the LDP port at the æall routers on this subnetÆ
group multicast address by means of a User Datagram Protocol (UDP)
packet [1]. Given the Hello procedure of LDP [1] and the
multicasting extensions of the Hello message (presented in section
2.2), this document will assume that each LSR knows of the other
LSRs in the MPLS network.
3.2.1. Construction of a LDP Multicasting Distribution Tree
In order to provide a mechanism for a point-to-multipoint LSP tree
to be constructed, the calculation of the tree must be done by a
mechanism that does not rely on external protocols or mechanisms.
The calculation of the tree must be done before any other mechanisms
for delivering data have been established. The tree can be
constructed based on two different contexts: root-initiated tree
calculation, and leaf-initiated tree calculation. The root-initiated
tree calculation should be used when a new source of multicasting
Jong-Moon Chung, et al. February 2002 Page <12>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
traffic is going to start delivering traffic to all the members of a
group. The leaf-initiated tree calculation is implemented when a new
member of a group wishes to receive the multicasting traffic,
implementing a request-driven scheme.
In addition, this document enables the multicasting functions of LDP
to be independent of traditional IP-based multicast routing
protocols, such as, DVMRP, MOSPF, PIM, etc. However, IGMP mechanisms
will be used to provide the functionalities for establishing and
maintaining multicasting group memberships.
Some key issues in constructing the tree are the Traffic Engineering
(TE) parameters that provide the Differentiated Services (DS) [10]
and Quality of Service (QoS) features. With these considerations,
the tree can be built based on:
1. Tree construction by means of source controlled routing,
2. Tree calculation by means of using traditional algorithms such
as the distance vector (DV) or link state (LS) algorithms that are
solely based on distance oriented metric values, or
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.
3.2.2. Root-Initiated Tree Calculation
The calculation and construction of the tree must be performed based
on the nodes/LSRs that have active members (hosts) that wish to
receive multicasting traffic. We assume that they have been either
pre-defined (by means of exchanging Hello messages) or they will be
joining dynamically following a random behavior.
To properly calculate the tree, an IGMP group definition table is
needed in order to proceed. This information is stored in a
Multicasting Information Database (MIDB) table located in all of the
participating LSRs. If the IGMP information is not available, then
the tree can be calculated by using the Hello message multicasting
extensions described in section 2.2.
3.2.2.1. Calculation based on IGMP information
Based on the IGMP membership information for a specific group, the
calculation for the tree can be done quickly based on one of the
methods described in Section 3.2.1. For example, extensions to the
Bellman-Ford algorithm allow the construction of a distribution tree
to be based on the Traffic Engineering parameters and the
metric/cost criteria, rather than just the metric criteria. These
extensions allow the creation of a shortest path tree that meets TE
requirements from a specific source in order to deliver multicasting
traffic complying with the DS and QoS parameters. The definition of
these extensions is beyond the scope of this document.
Jong-Moon Chung, et al. February 2002 Page <13>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
With the information gathered and stored in the MIDB, the root LSR
constructs the distribution tree (step (1)). The root LSR will send
out Label Request messages to the LSRs of the multicasting tree to
establish a LSP tree connection (step (2)). This will be confirmed
by Label Mapping messages 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).
Distribution Calculation based on MIDB information
+-----------+
| MIDB |
+-----+-----+
(3)Multicasting | |(1)Multicasting Tree |(2)Label Request
Traffic | V Database Information| message is sent
+-----------+ --> +-----+-----+ V to all LSRs of
| Source +-----+ Root LSR | the tree.
+-----------+ +-----+-----+
| |(4)Multicasting Traffic
| V (5) (6)
+-----+-----+ --> +-----------+ --> +-----------+
| LSR +-----+ LSR +-----+ Receiver 1|
+-----+-----+ +-----------+ +-----------+
| |(5)
| V (6) (7)
+-----+-----+ --> +-----------+ --> +-----------+
| LSR +-----+ LSR +-----+ Receiver 2|
+-----------+ +-----------+ +-----------+
3.2.3. Leaf-Initiated Tree Calculation
Since the distribution tree cannot be assumed static, a mechanism
that allows dynamic calculation of the trees is necessary. A tree is
normally recalculated when a node has to either join or leave the
tree issuing the corresponding recalculation messages. The proposed
messages to enable MPLS multicasting operations with LDP are defined
in the following sections. For the calculation of a tree, there must
be an existing multicasting source; hence the leaf-initiated tree
topology establishment is based on a predefined source already
multicasting. 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 (i.e., leaf node) wants to become a part of the
multicasting tree, it will send a LDP Multicast message with a Join
command to one of the LSR-RPs. The receiving LSR-RP will send this
Join command (Multicasting message) to the root LSR. If the leaf
node is granted permission to join the multicasting tree the root
LSR will initiate a Notification message (with multicasting
extensions) towards a LSR-RP. This LSR-RP will be the selected LSR
to establish a connection to the new host, where this LSR-RP may or
Jong-Moon Chung, et al. February 2002 Page <14>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
may not be the LSR-RP that the new host originally contacted with
the Join command. The selected LSR-RP will then issue a Label
Request message to the new host to establish a new LSP. The
Notification message used by the root LSR may have the multicasting
extensions of section 2.3.
Leaf-Initiated Tree Calculation
+---------+ +-----------+
| Source +---+ Root LSR +
+---------+ +-----+-----+
(3)Notification| | ^ (2)Join (1)Join Command
Message with | | | Command (Multicasting Message)
Multicasting V | +---- <-------
Extensions+-----+-----+ +-----------+ +------------+
| LSR-RP +-----+ LSR-RP +-----+ New LSR |
+-----+-----+ +-----------+ +------------+
| ----------> ------->
| (4)Notification (5)Label Request Message
| Message <-------
| (6)Label Mapping Message
|
+-----+-----+ +-----------+
| LSR +-----+ LSR +
+-----------+ +-----------+
3.2.4. Dynamic Updates to the Tree
Given the dynamic nature of the trees, constant adjustments to the
tree have to be performed. When a LSR does not have any more
multicasting receivers, it will issue a Multicasting message with a
Leave command, which will be sent to the upstream LSR in order to
stop the multicast traffic. The upstream LSRs will perform the
following procedures:
1. If the LSR that is leaving is not the last LSR within the tree,
then the upstream LSR will send a Leave command to its upstream
LSR-RP, where this LSR-RP will then issue a Leave command to
the root LSR. 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. The root LSR will send a Notification message
(with Multicasting extensions) to the LSR-RP. Following this,
the LDP standard label release procedures will be conducted
over the connection between the LSR-RP and the leaving LSR [1].
2. If a tree recalculation is conducted, the root LSR will trigger
a re-calculation procedure via a Notification message so all
the LSRs can use the updated LSR-RP 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
Multicasting message with a Leave command to the root LSR. The
Jong-Moon Chung, et al. February 2002 Page <15>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
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 Notification 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 Label Release procedures will be conducted to disconnect
the LSR. A destroy procedure will be used only when necessary,
otherwise, the multicasting session will be kept alive, such
that new users can establish a new multicasting tree if
necessary.
5. In the event that the source has no more multicast content to
multicast, it will issue a Multicasting message with a Destroy
command 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. Conclusions
Achieving multicasting based on traffic engineering constraints is
feasible by means of extending the capabilities of the LDP. By using
the LDP TE constraints, the necessary guarantees for end-to-end
traffic delivery can be provided, allowing service providers or
carrier companies to ensure customer data transmission to be
effective and allow service agreements to be maintained.
The use of the multicasting extensions to LDP dramatically reduces
the overhead generated in comparison to using multicasting routing
protocols as middleware between the IP and data link layers.
Specifically, by including the Multicasting TLV, and having the
Join, Leave, and Destroy commands as part of the Multicasting
message in conjunction with IGMP capabilities, the complete
construction of a multicasting distribution tree using only IP
multicast addressing information is possible.
5. References
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
Thomas, B., ææLDP Specifications,ÆÆ RFC 3036, Jan. 2001.
[2] Bradner, S., ææThe Internet Standards Process,ÆÆ RFC 2026, Oct.
1996.
[3] Awduche, D., Malcolm, J., Agogbua, J., OÆDell, M., and McManus,
J., ææRequirements for Traffic Engineering Over MPLSÆÆ, RFC 2702,
Sept. 1999.
[4] 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, USA, Aug. 8-
11, 2000.
[5] 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.
Jong-Moon Chung, et al. February 2002 Page <16>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
[6] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y.,
Rasiah, P., and Soo, H. M., ææRSVP Extensions for MPLS
Multicasting Services,ÆÆ submitted, IEEE Network.
[7] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y.,
and Rasiah, P., ææLDP Extensions for MPLS Multicasting Services,ÆÆ
submitted, IEEE Network.
[8] Deering, S., ææHost Extensions for IP Multicasting,ÆÆ RFC 1112,
August 1989.
[9] Fenner, W., ææInternet Group Management Protocol, Version 2,ÆÆ RFC
2236, Nov. 1997.
[10] Jamoussi, B., Aboul-Magd, O., Ashwood-Smith, P., Hellstrand,
F., Sundell, K., Andersson, L., Callon, R., Dantu, R., Wu, L.,
Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
Gray, E., Halpern, J., Heinanen, J., Kilty, T. Malis, A., and
Vaananen, P., ææConstraint-Based LSP Setup using LDP,ÆÆ work in
progress.
[11] Miller, K. C., Multicast Networking and Applications. Addison-
Wesley, 1999.
[12] Moy, J., ææMulticast Extensions to OSPF,ÆÆ RFC 1584, Mar. 1994.
[13] Ooms, D., Sales, R., Livens, W., Acharaya, A., Griffoul, F.,
and Ansari, F., ææFramework for IP Multicast in MPLS,ÆÆ work in
progress.
[14] Rosen, E., Viswanathan, A., and Callon, R., ææMultiprotocol
Label Switching Architecture,ÆÆ RFC 3031, Jan. 2001.
[15] Thomas, B., and Gray, E., ææLDP Applicability,ÆÆ RFC 3037, Jan.
2001.
[16] Whitmann, R. and Zitterbart, M., Multicasting Communication
Protocols and Applications. Morgan Kaufman Publishers, 1999.
[17] 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
Jong-Moon Chung, et al. February 2002 Page <17>
Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002
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 <18>
