The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS individual draft submission - MPLS WG
Dear IETF Secretariat, MPLS
chairs Title
: Requirements for multicast service using a group label over MPLS Abstract As the group communication becomes more important,
the special label should be
allocated in support of group management and maintenance. The allocation mechanism of a group
label can be applied to a point- to-multipoint(P2MP)
communication in MPLS networks. Currently used label is
locally significant, while this group label should be common object within a
single MPLS domain. This document presents a set of
requirements for multicast service using a group
label over Multiprotocol Label Switching(MPLS). It identifies
functional and performance capabilities required to allocate a
group label in master-slave network and peer to peer network, which
facilitates efficient and reliable group communication and Quality of
Service(QoS) in MPLS domain. It also identifies functional
capabilities required to implement convergence services related to
Content Distribution Network(CDN) and Virtual Private Network(VPN).
These capabilities can be used to provide high quality and scalable
service. This document includes the allocation
mechanism of a group label in order to
perform unidirectional P2MP communication. Your feedback will be very
much appreciated. Could you give me 10 min to
make a presentation?
Min Suk
Sung (mssung@icu.ac.kr) Broadband
Network Laboratory (http://bnlab.icu.ac.kr/)
Internet Draft Jun Kyun Choi
Document: draft-choi-mpls-grouplabel-requirement-01.txt Min Suk Sung
Expiration Date: April 2004 ICU
Sun Hee Yang
Hyoung Jun Kim
Jae Hoon Yoo
Hyeong Ho Lee
ETRI
November 2003
Requirements for multicast service using a group label over MPLS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026.
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 obsolete 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
As the group communication becomes more important, the special label
should be allocated in support of group management and maintenance.
The allocation mechanism of a group label can be applied to a point-
to-multipoint(P2MP) communication in MPLS networks. Currently used
label is locally significant, while this group label should be common
object within a single MPLS domain.
This document presents a set of requirements for multicast service
using a group label over Multiprotocol Label Switching(MPLS). It
identifies functional and performance capabilities required to
allocate a group label in master-slave network and peer to peer
network, which facilitates efficient and reliable group communication
and Quality of Service(QoS) in MPLS domain. It also identifies
functional capabilities required to implement convergence services
related to Content Distribution Network(CDN) and Virtual Private
Choi, et. al. [Page 1]
Requirements for multicast service using a group label
over MPLS November 2003
Network(VPN). These capabilities can be used to provide high quality
and scalable service.
This document includes the allocation mechanism of a group label in
order to perform unidirectional P2MP communication.
0. Comparison with "draft-yasukawa-mpls-p2mp-requirement-00.txt"
(This section is to be removed before publication.)
0.1 this document
We propose a group label which is globally unique within a single
MPLS domain and then provide multicast service using a group label.
This document presents a set of requirement for multicast service
using a group label over MPLS and then identifies allocation
mechanism of a group label to perform unidirectional point to
multipoint(P2MP) connection. In comparison with 'draft-choi-mpls-
grouplable-requirement-00.txt' document, we add the requirement of
CDS/VPN convergence network to this document.
0.2 draft-yasukawa-mpls-p2mp-requirement-00.txt
This document presents a set of requirement for P2MP capability
extension to Multiprotocol Label Switching(MPLS). The functional and
performance extensions about Content Distribution Network(CDN) and
CDN/VoIP/VPN service convergence network are described.
0.3 differences
our draft considers multicast service using a group label in two
kinds of network. One is master-slave network. The other is peer to
peer network. Requirements, allocation mechanism of a group label and
service type can be dealt with each network topology.
On the other hand, yasukawa’s draft refers to a set of CDN service
and other service convergence network. Then, P2MP extensions which
are required to these services are identified.
Conventions
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.
Choi, et. al. [Page 2]
Requirements for multicast service using a group label
over MPLS November 2003
Table of Contents
1. Introduction.....................................................4
2. Definition.......................................................4
2.1 Group Label.....................................................4
2.2 Group Communication based on Client-Server Model................5
2.3 Group Communication based on Peer Model.........................5
3. Requirements for Multicast Service using a Group Label...........5
3.1 Master-Slave Network............................................5
3.1.1 Group Label distribution......................................5
3.1.2 Group Label Management........................................6
3.1.3 Designing the position of master node.........................6
3.1.4 QoS Control for P2MP Communication using a Group Label........7
3.1.5 Traffic Engineering for P2MP connection using a Group Label...7
3.1.6 IPv4 / IPv6 support...........................................7
3.1.7 Interoperability between P2P and P2MP connection..............7
3.2 Peer to Peer Network............................................7
3.2.1 Group Label distribution......................................8
3.2.2 Group Label Management........................................8
3.2.3 Scalability...................................................8
4. Requirements for service convergence network.....................9
4.1 Service Type....................................................9
4.2 CDS/VPN service convergence network............................10
4.2.1 Multicast routing information mechanism......................10
4.2.2 Tunneling mechanism..........................................10
4.2.3 Security support.............................................11
5. Communication Mechanism for Multicast Service...................11
5.1 Procedures for setting up Unidirectional P2MP Communication....11
5.2 Joining Mechanism..............................................12
5.3 Leaving Mechanism..............................................13
6. Extended Format for Multicast Service...........................13
6.1 Required Message...............................................13
6.1.1 Path Message.................................................14
6.1.2 Resv Message.................................................14
6.2 Extended Object................................................15
6.2.1 Hello object for Group Management............................15
6.2.2 Group Label Object...........................................15
6.2.3 Group Label Request Object...................................16
Security Considerations............................................16
References.........................................................16
Author's Address...................................................18
Choi, et. al. [Page 3]
Requirements for multicast service using a group label
over MPLS November 2003
1. Introduction
It is increasingly important to guarantee real-time application
requiring more strict QoS and higher bandwidth such as Internet
broadcasting, video conferencing and real-time delivery services,
therefore the group communication will become very useful for these
purposes. The special label should be allocated in support of group
management and maintenance. The allocation mechanism of group label
can be applied to a point to multipoint(P2MP) communication.
In existing MPLS technology, label switching is done so that fast and
simple forwarding can be performed and this label is local
significant.
In order to facilitate group communication, a group label which is
globally unique within a single MPLS domain should be supported. This
label can distinguish each P2MP LSP when a edge node joins several
P2MP connections.
This multicast service using a group label can be applied Layer 2
Virtual Private Network(L2VPN). The group label is the same role as
VPN ID. Therefore, a single VPN can be communicated with other VPNs
within P2MP connection using a group label.
A group label is allocated using Resource Reservation Protocol-
Traffic Engineering(RSVP-TE). Appropriate admission control should be
done according to requested QoS degree.
In case of multicast or broadcast traffic type, branch node should
perform replication function for path message and merging function
for resv message.
Using QoS mechanism such as Differentiated Service(DiffServ), we can
provide prioritized service. Billing mechanism also can be applied.
This document presents a set of requirements for multicast service
using a group label over Multiprotocol Label Switching(MPLS). It
identifies functional and performance capabilities required to
allocate a group label in master-slave network and peer to peer
network, which facilitates efficient and reliable group communication
and Quality of Service(QoS)in MPLS domain. It also identifies
functional capabilities required to implement convergence services
related to Content Distribution Network(CDN) and Virtual Private
Network(VPN). This document includes the allocation mechanism of a
group label in order to perform unidirectional P2MP communication.
2. Definition
2.1 Group Label
A group label is a common object to establish and maintain the P2MP
connection and globally unique within a single MPLS domain.
Choi, et. al. [Page 4]
Requirements for multicast service using a group label
over MPLS November 2003
The allocation mechanism of a group label is done in two kinds of
network using RSVP-TE signaling protocol. One is server-client based
network and the other is peer to peer based network.
2.2 Group Communication based on Client-Server Model
A single Server is equipped with the concept of multipoint control
unit (MCU) which can enable two or more receivers to intercommunicate
with a single sender like conferencing. So, the P2MP connection can
be established using a single server locally. This server has two
functions; one is a replication function for Path message with group
label request object and the other is a merging function for Resv
message with group label.
It is totally reliable and robust to establish this communication
because a server manages the traffic engineered explicit routes to
avoid link failure before forwarding a Path message from a sender.
2.3 Group Communication based on Peer Model
This model doesn’t need any server and hello message for group
management because a LSR which wants to establish P2MP connection can
directly send Path message containing group label request to all of
the LSRs within a MPLS domain. A LSR which sends Path message doesn’t
know who will receive. All of the LSRs which received Path message
determine whether to join a P2MP connection. If they accept the
request, they send Resv message with group label. Otherwise, they
ignore the request. After receiving Resv messages from LSRs, the P2MP
connection between a single sender and multiple receivers can be
established within a MPLS domain. The common group label should be
used in this communication.
In peer model, there are much smaller overhead for messages and
maintaining a server with a huge database. On the other hand, the
failing possibility to establish a P2MP connection is much higher
than the client-server model, since a server which chooses traffic
engineered explicit route between a sender and receivers doesn't
exist.
3. Requirements for Multicast Service using a Group Label
3.1 Master-Slave Network
3.1.1 Group Label distribution
Using RSVP-TE signaling protocol for allocating a group label,
messages of RSVP-TE can be distributed differently according to the
incoming traffic type toward master. In case of unicast traffic, Path
message is distributed through the route so that a group label can be
assigned to each LSR of the route in point to point(P2P) connection.
In multicast or broadcast traffic, master should be capable of
Choi, et. al. [Page 5]
Requirements for multicast service using a group label
over MPLS November 2003
replicate Path message the same as the number of receiver. A master
also should have merging function to forward RSVP message from
multiple receivers toward a single sender.
P2MP connection has different dynamics compared with P2P connection
because the topology of receivers is changed frequently. A group
label is required to distinguish each P2MP connection
O Joining Mechanism
Master can have both all P2MP connection and corresponding group
label information. A receiver can dynamically request to join a
certain P2MP communication. If the joining request of new node is
traffic-negotiable, master assigns the group label which is exactly
matched to requested P2MP communication. Otherwise, that request must
be rejected.
Each master of the P2MP connection is required to check the residual
resource and traffic parameter such as delay, loss, etc.
O Leaving Mechanism
In case the already joined node wants to leave in the P2MP session
with the group label of certain QoS level, that node can request to
the master. Then, the explicit route of the receiver is torn down.
Since the process of joining or leaving is dynamically performed, a
master should periodically check the correct and updated information.
3.1.2 Group Label Management
After establishing a P2MP connection, a common group label is
assigned to all the LSRs within the P2MP connection. A master should
have the topology information of established P2MP connection and
mapped group label information. Besides, whenever adding or removing
a leaf node, master should have correct updated information.
In customer's place, satisfactory service can be provided because of
distributing a group label in advance. Therefore, service
verification is easily done through group label management.
3.1.3 Designing the position of master node
P2MP capability can largely improve the effective usage of network
resources such as bandwidth and link utilization. Therefore, the
calculation of master's location as a branch node is automatically or
administratively required to be done in order to place at optimal
position.
It also is required to use information related to underlying protocol
such as IGP traffic engineering extension or offline management tool.
Choi, et. al. [Page 6]
Requirements for multicast service using a group label
over MPLS November 2003
3.1.4 QoS Control for P2MP Communication using a Group Label
A common group label is assigned to each P2MP communication. The
group label is required to identify each P2MP connection as well as
control QoS level regarding bandwidth, delay, loss and other
performance parameters.
Therefore, QoS control by a group label should support QoS or Class
of Service(CoS) such as Expedited Forwarding(EF), Assured
Forwarding(AF) and Default(Best Effort) style of differentiated
service.
3.1.5 Traffic Engineering for P2MP connection using a Group Label
Because of frequent changes of topology in joining or leaving leaf
nodes, traffic engineering including fault location detection and
fault recovery should be considered as a important function. In case
link failure occurs in P2MP connection using a group label, the
information related to failure is promptly advertised to a master and
rerouting function should be performed. At that time, rerouted
explicit route is done according to administrative policy. The most
important requirements on the rerouting process is to avoid traffic
disruption.
Therefore, the concept of make-before-break is strongly recommended.
This shares resources in the common part where both old P2MP and new
P2MP connection exist. After breaking down old P2MP connection,
the used traffic and resources is switched to new P2MP connection so
that rerouting can be successfully done.
In P2MP topology, a single common rerouting mechanism is required
because multiple paths can be rerouted at once.
3.1.6 IPv4 / IPv6 support
This extension must support both IP4/IPv6 transmissions
3.1.7 Interoperability between P2P and P2MP connection
According to incoming traffic type toward sender, a master should use
ether P2P or P2MP efficiently. It also should be supported that
multiple P2P connection are aggregated to establish P2MP.
In case a P2P connection is needed over already established P2MP
connection using a group label, group label space should be shared
between P2P and P2MP connection. Link resource is also required to be
shared between P2P and P2MP connection.
3.2 Peer to Peer Network
Choi, et. al. [Page 7]
Requirements for multicast service using a group label
over MPLS November 2003
3.2.1 Group Label distribution
Using RSVP-TE signaling protocol for allocating a group label, All
nodes should distribute Path messages to every nodes within a single
MPLS domain. After receivers check whether requested QoS is
acceptable, receivers sends Resv message to only reasonable nodes. A
node becomes a sender and a receiver at the same time. Therefore, a
single MPLS network consists of P2MP connection using a group label
in a full mesh topology.
In order to process multicast or broadcast traffic, all nodes within
a single MPLS domain are required to perform replication and merging
function.
All P2MP connections should accommodate P2P as well as P2MP
communication according to customer request.
O Joining Mechanism
Since there is not any master in a P2MP connection, all nodes can
directly join at any time, however all nodes joining certain P2MP
communication should inform other group members.
Other group members can reject a new request according to residual
resource and traffic parameter such as delay, loss, etc.
O Leaving Mechanism
In case the already joined node wants to leave in the P2MP session
with the group label of certain QoS level, that node can notify other
group members and then immediately leave. Then, the explicit route of
the receiver is torn down.
Since all nodes can perform the process of joining or leaving for
themselves, each node should periodically check the correct and
updated information.
3.2.2 Group Label Management
All nodes can manage only certain group label which they use. That is,
each node is required to have the information of group label which
belongs to itself. For example, the node which attends two kinds of
P2MP communication should manage two different group labels.
3.2.3 Scalability
In this network, joining or leaving process is performed regardless
of the memory size of master. A node easily joins or leaves through
exchanging the information of a group label each other so that this
can be a scalable solution.
Since unlimited scalability can reduce QoS, appropriate policy is
required.
Choi, et. al. [Page 8]
Requirements for multicast service using a group label
over MPLS November 2003
4. Requirements for service convergence network
4.1 Service Type
We can classify P2MP service style of master-slave network
environment as a Content Distribution Service(CDS). The
representative services of CDS are Live Video Distribution, Video
Broadcasting, Video-on-Demand service, etc. These services have the
following features. First, they require much higher bandwidth. Second,
they should last longer session-on-time. Third, they are very
sensitive to delay.
O Live video Distribution
This service is to distribute live video streaming to multiple users
on demand basis. The sports real-time broadcasting or e-learning is a
delegate example of this service.
The basic operation is as follows. A streaming server per Provider
Edge(PE) node is located and video stream data is transmitted through
this server. Customers who are about to join or leave at certain
session need authentication at first and then are able to join or
leave using session control signaling. Therefore, P2MP connection
using a group label is dynamically created according to the location
of receivers.
Resource is also dynamically assigned according to receiver request.
When a session is established, a proper resource is assigned and when
the session is over, resource is released. Therefore, efficient and
effective resource management is required.
O Video Broadcasting Service
This service is to distribute streaming data to multiple users on
static connection basis. Digital broadcasting is a delegate example.
The basic operation is as follows. A broadcast streaming server is
located in center and provides services using multicast technology. A
static P2MP connection is established between a sender and multiple
receivers. Therefore, a single static P2MP connection can have
multicast capability.
In customer's place, customers can choose necessary video channel
from multiple service channels and then enjoy various service. That
is, the service environment which is equipped with high quality,
multiple channels and multiple functions can be realized.
In service provider's place, service providers can easily keep a
number of demands through high quality service of digital
broadcasting. Keeping extra frequency band through multiple channels
is important effect and multiple functions can improve revenue
potentially.
Choi, et. al. [Page 9]
Requirements for multicast service using a group label
over MPLS November 2003
O Video on Demand Service
This service is to distribute streaming service to a single receiver
on demand basis.
The basic operation is as follows. An original VoD streaming server
is located at center and provides services using unicast method. Then,
several mirror servers are located at near receivers. In case load
becomes significantly larger at central server, mirror server is
required in order to decentralize the load.
Therefore, multiple static P2P connections between a sender
accommodating central server and a receiver are established and also
between a sender accommodating mirror server and a receiver.
This concept decentralizes server load capable of providing services
so that QoS of video traffic can be guaranteed. A central server
checks remaining bandwidth of each P2P connection and enable new node
to join corresponding P2P communication according to requested QoS
whenever incoming requests. Therefore, connection failure can be
occurred frequently because multiple traffic streams can be entered
to a single P2P connection.
In order to improve transmission quality and reliable operation, fast
reroute mechanism is needed.
4.2 CDS/VPN service convergence network
This extended capability must be applicable to CDS/VPN service
convergence network. There are several advantages in terms of
integrating CDS and VPN service. First, we can get cost-efficient
about expanding existing network. Second, scalability and mobility
are supported to provide convenient network environment as remote
place, mobile users and telecommuting users increase. Second,
flexible network operation and management can be realized.
4.2.1 Multicast routing information mechanism
To provide multicast service in the CDS/VPN convergence network, All
Provider Edges(PEs) must exchange the information of P2MP
communication which each PE participates in. the information between
CEs connected to the PE is also require. As each PE gets more than
one VPN, each PE must get forwarding information table to distinguish
the path per interface.
4.2.2 Tunneling mechanism
P2P or P2MP Tunnel must be established between PEs. A group label is
inserted as a tunnel label at the ingress LER and maintained while
Choi, et. al. [Page 10]
Requirements for multicast service using a group label
over MPLS November 2003
passing a tunnel LSP. Then, this group label is removed at the egress
LSR, while existing MPLS label performs label swapping through LSRs.
4.2.3 Security support
VPN has possibility of degradation for security and performance in
comparison with dedicated network. To manage P2MP tunnel and policy
of VPN multicast, authentication and security protocol or mechanism
is required such as IPsec, L2TP, PPTP, etc.
5. Communication Mechanism for Multicast Service
5.1 Procedures for setting up Unidirectional P2MP Communication
All of the LSRs within a single MPLS domain can be a sender or
receiver. If a sender node is designated, rest of them becomes
receivers. There exists a server per MPLS domain. The following is
the procedures of setting up unidirectional P2MP communication.
1. All of the LSRS within a single MPLS domain send hello message to
a server so that the server can register each IP address and
explicit route of each LSR to the NIB. The server has the NIB
including IP address and explicit route. So, the server maintains
the NIB due to periodical transmission of a hello message.
2. If a single LSR sends the Path message containing group label
request to a server, all of the LSRs except for a sender become
receivers within a MPLS domain.
3. After choosing explicit routes registered in NIB, the server
copies group label request as the number of chosen explicit route
and sends the Path message including group label request.
4. Among nodes receiving the Path message containing group label
requet, the node which is ready to accept the group label request
and join the P2MP communication allocates group
label to the Resv message.
5. The server received several Resv messages containing group label
perform the merging function. Then, the server creates and sends
new Resv message containing group label to a sender.
6. After distributing the Resv message from multiple receiver to a
sender, the P2MP LSP is established and starts P2MP communication,
which a single sender and two
or more receivers are sharing the common group label.
+------------------------------------------+
| Hello |
| <------ |
Choi, et. al. [Page 11]
Requirements for multicast service using a group label
over MPLS November 2003
| +--------B |
| Hello +-----+ | |
| -------> | |<---+--------C |
| A--------->| S | |
| | |<---+--------D |
| +-----+ | |
| +--------E |
| <------- |
| single MPLS domain Hello |
+------------------------------------------+
Path
--------->
+----------------B
| <---------
| Resv
|
|
Path | Path
--------> +---+ --------->
A--------------| S |--------------C
<-------- +---+ <---------
Resv | Resv
|
|
| Path
| --------->
+----------------D
<---------
Resv
Figure 1. Set up for a point-to-multipoint connection
5.2 Joining Mechanism
After establishing P2MP communication, the following mechanism is
applied when a new LSR intends to join this group.
-
a new LSR sends a join message to a server.
-
The server stores the information extracted from a Join message in
NIB and then forwards the join message to the sender.
-
The sender received the join message sends a Path message
containing group label request to the server.
-
The server received the Path message sends it to the new LSR if
being traffic-negotiable about explicit route.
Otherwise, the server sends notification message to the sender and
teardown message to the new LSR.
-
The new LSR received the Path message sends Resv message to a
server.
-
Then, the server forwards it to the sender and the new LSR can
join the P2MP communication.
Choi, et. al. [Page 12]
Requirements for multicast service using a group label
over MPLS November 2003
The procedure of joining mechanism is illustrated in Figure 2.
+--------------------------B
| |
| . |
| . |
+---+ . |
A--------------| S |--------------C |
| +---+ |
| Join | Join |
|<--------------|<-----------------------|
| | |
| Path | Path |
|-------------->|----------------------->|
| | |
| Resv | Resv |
|<--------------|<-----------------------|
| | |
Figure 2. Joining mechanism
5.3 Leaving Mechanism
Among LSRs joining the P2MP communication, the LSR which intends to
tear down the connection sends a leave message to a server. The
server sends a notification message to the sender and a teardown
message to the LSR which requests to leave.
The procedure of leaving mechanism is illustrated in Figure 3.
+--------------------------B
| |
| . |
| . |
+---+ . |
A--------------| S |---------------C |
| +---+ |
| | Leave |
| Notification |<-----------------------|
|<--------------| |
| | |
| | teardown |
| |----------------------->|
| | |
Figure 3. Leaving mechanism
6. Extended Format for Multicast Service
6.1 Required Message
Choi, et. al. [Page 13]
Requirements for multicast service using a group label
over MPLS November 2003
6.1.1 Path Message
In case a single LSR within a MPLS domain creates a Path message with
label request which requires allocating group label and sends to the
server, the rest of LSRS becomes receivers. The server sends Path
message along the explicit routes registered in NIB. The modified
message is shown in Figure 4.
<path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <REVP-HOP>
<TIME-VALUE>
<GROUP-LABEL-REQUEST>
[ <SESSION-ATTRIBUTE> ]
[ <POLICY-DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER-TEMPLATE> <SENDER-TSPEC>
Figure 4. Path message
6.1.2 Resv Message
LSRs received path message from server allocate a group label as a
part of Resv message and is sent through the server to the sender
along the reverse path of Path message. The modified format of Resv
message is as follows in Figure 5.
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP-HOP>
<TIME-VALUE>
[ <RESV-CONFIRM> ] [ <SCOPE> ]
[ <POLICY-DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor list>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER-SPEC>
<GROUP-LABEL> [ <RECORD-ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER-SPEC>
<GROUP-LABEL> [ <RECORD-ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER-SPEC>
Choi, et. al. [Page 14]
Requirements for multicast service using a group label
over MPLS November 2003
<GROUP-LABEL> [ <RECORD-ROUTE> ]
Figure 5. Resv message
6.2 Extended Object
6.2.1 Hello object for Group Management
The purpose of this message is to allow a server to maintain the NIB.
The hello message with hello object periodically transmits to a
server. The modified hello object is shown in Figure 6. This object
has explicit route object to indicate a particular path from server
to each LSR within a MPLS domain.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src-Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst-Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flg|L| Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flg
If set to one, this message is used for group management.
Otherwise, this message doesn’t use explicit route object.
Figure 6. Hello object
6.2.2 Group Label Object
The group label is recognized to all of the LSRs within P2MP label
switched path of a single MPLS domain. Since the path message
reserves the traffic engineered explicit registered in NIB, this
label may be carried by Resv message and forwarded to the reverse
explicit routes.
If a node handles the Resv message with the common group label object,
this node can join the P2MP communication.
The group label object has the following format:
LABEL class = 16, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group label |
Choi, et. al. [Page 15]
Requirements for multicast service using a group label
over MPLS November 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Group label object
6.2.3 Group Label Request Object
To establish a P2MP communication, the sender creates path message
with label request object for group label allocation. This label
request object specifies the range of group label and triggers the
nodes registered in NIB to allocate a group label and to place the
group label of Resv message. The group label must be allocated from
that range. The group label request object is shown in Figure 8.
class = 19, C-Type = 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flg| Reserved | Minimum group label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum group label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flg
If set to one, it is used for group label request
Otherwise, it is used for generic label request.
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Figure 8. Label request object
Security Considerations
This document does not have any security concerns. The security
requirements using this document are described in the referenced
documents.
References
[1] D. Awduche, et al.. "Requirements for Traffic Engineering over
MPLS", September 1999.
[2] E. Rosen, et al.. "Multiprotocol Label Switching Architecture",
January 2001.
[3] L. Andersson, et al.. "LDP Specification", January 2001.
Choi, et. al. [Page 16]
Requirements for multicast service using a group label
over MPLS November 2003
[4] D. Awduche, et al.. "RSVP-TE: Extensions to RSVP for LSP Tunnels",
December 2001.
[5] B.Jamoussi, et al.. "Constraint-Based LSP Setup using LDP",
January 2002.
[6] D. Ooms, et al.. "Overview of IP Multicast in a Multiprotocol
Label Switching Environment", August 2002.
[7] S. Yasukawa, et al.. "Extended RSVP-TE for Point-to-Multipoint
LSP Tunnels-00", Internet Draft, January, 2003.
[8] "B-ISDN network requirements", ITU-T Recommendation I.313,
September 1997.
[9] S. Yasukawa, et al.. "Requirements for Point-to-Multipoint
capabilities extensions to MPLS", August 2003.
[10] W. Augustyn, et al.. "Service Requirements for Layer 2 Provider
Provisioned Virtual Private Networks", August 2003.
Choi, et. al. [Page 17]
Requirements for multicast service using a group label
over MPLS November 2003
Author's Address
Jun Kyun Choi
Information and Communications University (ICU)
58-4 Hwa Ahm-Dong, Yusong-Gu, Taejon
Korea 305-732
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Min Suk Sung
Information and Communications University (ICU)
58-4 Hwa Ahm-Dong, Yusong-Gu, Taejon
Korea 305-732
Phone: +82-42-866-6198
Email: mssung@icu.ac.kr
Sun Hee Yang
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6122
E-mail: shyang@etri.re.kr
Hyoung Jun Kim
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6576
E-mail: khj@etri.re.kr
Jae Hoon Yoo
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-1602
E-mail: jh-yoo@etri.re.kr
Hyeong Ho Lee
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6130
E-mail: holee@etri.re.kr
Choi, et. al. [Page 18]
|
|