One document matched: draft-yasukawa-mpls-p2mp-requirement-00.txt
MPLS Working Group Seisho Yasukawa (NTT)
Internet Draft Ichiro Inoue (NTT)
Expiration Date: August 2003
Februarly 2003
Requirements for Point-to-Multipoint capability extension to MPLS
<draft-yasukawa-mpls-p2mp-requirement-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 presents a set of requirements for Point-to-Multipoint
(P2MP) capability extension to Multiprotocol Label Switching (MPLS).
It identifies the functional and performance extensions required to
realize Content Distribution Network (CDN) by MPLS technology.
It also identifies functional extensions required to implement
CDN/VoIP/VPN sevice convergence network. These extensions can be used
to provide high performance and scalable broadband service network
with MPLS technology.
Yasukawa, et. al. [Page 1]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
Table of Contents
1. Introduction .................................................. 3
2. Terminology and conventions ................................... 3
2.1 Terminology ............................................... 3
2.2 Conventions ............................................... 5
3. Typical Network attribute and architecture of
Content Distribution Service................................... 5
3.1 Service type and its characteristics ...................... 5
3.2 Live video distribution service ........................... 5
3.3 Video Broadcasting service ................................ 7
3.4 Video on Demand service ................................... 9
3.5 Content Distribution Network architecture ................. 11
4. Requirements for P2MP capability exptension ................... 11
4.1 P2MP LSP tunnels .......................................... 11
4.2 P2MP LSP topoplogy and Tree explicit routing .............. 11
4.3 Calculation of P2MP Path .................................. 12
4.4 P2MP LSP establishment, teardown, and modification
mechanisms ................................................ 13
4.5 Management of P2MP LSP tunnels ............................ 13
4.6 QoS control of P2MP LSP tunnels ........................... 14
4.7 P2MP TE ................................................... 14
4.8 IPv4/IPv6 support ......................................... 15
4.9 P2P and P2MP LSP establishment ............................ 15
4.10 Interworking function with IP multicast .................. 15
5. Requirements for Service convergence network .................. 15
5.1 CDN/VoIP/VPN service convergence network .................. 15
5.2 VPN Multicast ............................................. 15
6. Security Considerations........................................ 15
7. Acknowledgements .............................................. 16
8. References .................................................... 16
9. Author's Addresses ............................................ 17
Yasukawa, et. al. [Page 2]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
1. Introduction
With rapid dissemination of broadband IP access services, like xDSL
and FTTH, many service providers seek a chance for deploying new
broadband IP services networks for their customers. Among multiple
candidates, Content Distribution (CD), Voice over IP (VoIP) and
Virtual Private Network (VPN) services are the most attractive
broadband services to service provider and their customers.
To differentiate these services from conventional best effort
Internet access service, Quality of Service (QoS) control, Traffic
Engineering (TE) and Reliability control mechanisms are required to
broadband IP service network. Because MPLS already has all of these
mechanisms in its protocol architecture, it is assumed that
developing broadband IP service network by MPLS technology is most
the promising way.
But many of these services, such as video broadcasting, video
conference and VPN multicast service require not only P2P
transmission capability but also P2MP transmission capability
with much stricter QoS control, more sophisticated TE and more stable
reliability control requirement. Therefore, P2MP capability extension
is required to conventional MPLS.
This manuscript presents a set of requirements for P2MP capability
extensions to MPLS. It identifies the functional and performance
extensions required to realize Content Distribution Network (CDN)
by MPLS technology. It also identifies functional extensions required
to implement broadband service convergence network.
2. Terminology and conventions
2.1 Terminology
The reader is assumed to be familiar with the terminology in [1],
[2], [3] and [4].
P2P:
Point-to-point
P2MP:
Point-to-multipoint
P2MP LSP:
Yasukawa, et. al. [Page 3]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
A label switched path that has one unique ingress lsr (also
referred to as the root) and more than one egress label switching
router.
sender node:
Headend of the P2MP LSP. It controls the P2MP LSP layout
and places traffic onto it by pushing a label.
Branch LSR:
A label switching router (LSR) that has more than one downstream
LSR. A branch LSR receives a single MPLS frame, makes a duplicate
of it, and sends each to downstream interfaces.
join leaf node:
A leaf node trying to join a P2MP LSP.
leave leaf node:
A leaf node trying to leave a P2MP LSP that it has joined
graft node:
An LSR that is already a member of the P2MP tree and is in
process of signaling a new subtree.
prune node:
An LSR that is already a member of the P2MP tree and is in
process of tearing down an existing subtree.
Subtree:
A subtree is a portion of a P2MP tree starting at a particular LSR
that is a member of the P2MP tree and includes ALL downstream
nodes that are also members of the P2MP tree.
EPG:
Electric Program Guide.
NWA:
Network Agent is an agent which authenticates client's IGMP
message and performs call admission control considering network
resource.
Yasukawa, et. al. [Page 4]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
RTSP:
Real Time Streaming Protocol.
2.2 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 RFC2119 [5].
3. Typical Network attribute and architecture of Content Distribution
Service
3.1 Service type
Major candidates for CDS are Live video distribution, video
broadcasting and video-on-demand service.
Typical bandwidth of these streaming service ranges from 500kbps to
6Mbps because they are encoded and transmitted by MPEG4 and
MPEG6 compression technology.
These streaming services have the following characteristics. Each
streaming service require much higher bandwidth, and has longer
session-on-time compared with conventional IP session. And these
service are very sensitive to packet loss.
Therefore, these streaming services require tight QoS control.
3.2 Live video distribution service
Live video distribution service is one of the streaming service
which distribute live streaming video data to multiple users on
demand basis. Live video distribution from baseball park or concert
hall and e-learning are examples of this service.
In this service, a streaming server can attach and transmit live
video streaming data to any of the provider edge nodes in this
netwok. And any of customer can Join and Leave this streaming service
by its session control signaling after authentication. Depending on
the locations of the streaming receivers, a single P2MP lsp is
established dynamically between a sender edge node and receiver
edge nodes. It is desirable that this single P2MP lsp convey single
IP multicast traffic that is transmitted by this streaming source.
And it is desirable that network resource are reserved dynamically
depending on reciever's viewing status. This means that unnecessary
leaf LSP that composed of P2MP LSP must be torn down dynamically
when all of the receivers that belong to this leaf edge node leave
Yasukawa, et. al. [Page 5]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
from this service. And vice versa, necessary leaf LSP must be
established dynamically between branch LSR and leaf edge nodes when
a receiver newely join in this service. The P2MP LSP is totally torn
down when streaming source finish transmitting the data or all of
reciever leave from this service.
Considering the situation that live video streaming service request
real time transmission with small delay variation and dynamics of
P2MP LSP topology, it is desirable to use Shortest Path Fast (SPF)
algorithm [DJIKSTRA] when calculating P2MP LSP topology.
Tree size of P2MP LSP varies greatly according to application type of
Live streaming service. It is assumed that leaf size changes from a
small number of nodes to a thousand nodes according to the
application. But bandwidth of live streaming is small and its
influence is not big. Therefore it is better to setup a P2MP LSP with
delay optimized topology even if the P2MP LSP has big leaf size.
Following figure shows one of the example of joining sequence for
Live streaming video service. In this example, a client request
Content Platform (CPF) of EPG. After passing authentication, client
receive EPG from CPF. Selecting live video streaming channel, client
request CPF of encryption decoder key. Recieving an encryption key,
client request leaf node of a multicast streaming data by IGMP with
authentication key[IGAP]. This message is transffered to NWA for
authentication. After authentication performed by NWA, NWA setup a
leaf LSP between Graft node and Leaf node and enable IGMP Join
operation on leaf node. In this way, P2MP LSP is dynamically set and
live video streaming data is transmitted to the client.
Yasukawa, et. al. [Page 6]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
+-----+ +-----+
| CPF |<=>| NWA |
+-----+ +-----+
/ / \ \
/ / \ +--------------+
/ / \ \
+------+ +--------+ +--------+ +--------+ +------+
|client|-----| Leaf N |-------|Graft N |-------|Sender N|-----|server|
+------+ +--------+ +--------+ +--------+ +------+
| | | | | | |
|---EPG Req---|>| | | | |
|<--EPG Rep---|-| | | | |
|---Key Req---|>| | | | |
|<--Key Rep---|-| | | | |
| | | | |<=== Live video stream ========|
|--- IGMP --->| | | | | |
| |-|--Auth-->| | | |
| |<|---Auth--| | | |
|<-- IGMP ----| | |----|-Graft request ->| |
| |<|-- Path -|----|<---- Path ------| |
| |-|-- Resv -|--->|----- Resv ----->| |
|<============|=|======== |====|==== Live video stream ========|
| | | | | | |
Figure 1 Live video streaming service sequence
Several schemes exist to setup a P2P leaf LSP in addition to a scheme
disribed above. Implementing scheme is decided based on network
management policy.
3.3 Video Broadcasting Service
Video Broadcasting Service is one of the streaming service which
distribute streaming video data to multiple users on static basis.
IP/TV is one of this service.
In this service, a broadcast streaming server is placed at central
data center and it transmits streaming contents by IP multicast
technology. A static P2MP LSP is established between a sender edge
node and all of the leaf nodes which accomodate broadcast receivers.
It is desirable that single P2MP LSP convey multiple IP multicast
streaming traffic. Therefore, all of broadcast streaming data are
transmitted to leaf edge node in static manner.
In this service model, a receiver can enjoy watching video stream by
selecting necessary video channel from multiple channel.
Yasukawa, et. al. [Page 7]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
This P2MP LSP can be utlized as backbone technology for both IP/TV
application and CATV application.
If a service provider want to provide 50 broadcast streaming channel
by MPEG2 technology which has 6Mbps transmission bandwith. The P2MP
LSP must handle 300Mbps broadcast video streaming traffic in a single
P2MP LSP.
Considering the influence of this big bandwith and the situation that
these video stream are transmitted to every leaf edge node in static
manner, it is desirable to use Steiner tree calculation algorithm
[STEINER] that can minimize the necessary transmission bandwidth of
this P2MP tree.
Tree size of P2MP LSP varies greatly according to application type
of video broadcasting service. But it is easily assumed that leaf
size becomes up to a thousand when realizing a nation wide broadcast
service.
To enable scalable operation, a mechanism that can change bandwidth
of established P2MP LSP freely witout disrupting transmission is
useful. It is also useful to provide partial P2MP tree modification
mechanism because it enables scalable network design and operation.
Following figure shows one of the example of service sequence for
video broadcasting service. In this example, a client request CPF of
EPG. After passing authentication, client receive EPG from CPF.
Selecting video broadcast channel, client request CPF of encryption
decoder key. Recieving encryption key, client request leaf node of a
multicast streaming data by IGMP with authentication key[IGAP]. This
message is transffered to NWA for authentication. After
authentication performed at NWA, NWA enables IGMP Join operation on
leaf node. After this process, requested video streaming data is
transmitted to the client.
Yasukawa, et. al. [Page 8]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
+-----+ +-----+
| CPF |<=>| NWA |
+-----+ +-----+
/ / \ \
/ / \ +--------------+
/ / \ \
+------+ +--------+ +--------+ +--------+ +------+
|client|-----| Leaf N |-------|TransitN|-------|Sender N|-----|server|
+------+ +--------+ +--------+ +--------+ +------+
| | | | | | |
| |<|=========|====|== Video broadcast stream ====|
|---EPG Req---|>| | | | |
|<--EPG Rep---|-| | | | |
|---Key Req---|>| | | | |
|<--Key Rep---|-| | | | |
|--- IGMP --->| | | | | |
| |-|--Auth-->| | | |
| |<|---Auth--| | | |
|<-- IGMP ----| | | | | |
|<============|=|=========|====|=== Video broadcast stream ===|
| | | | | | |
Figure 2 sequence example of video broadcast service
3.4 Video on Demand Service
Video on Demand Service is one of the streaming service which
distribute streaming video data to single user on demand basis.
Therefore, a user can enjoy watching video from start to end at
any time he request.
In this service, an original VoD streaming server is placed at
central data center and it transmits streaming contents by IP
unicast technology. And several mirror servers are placed at
mirror sites which are located near the leaf nodes. To decentralize
server's load, appropriate server is selected considering server's
load and clients location.
Multiple static P2P LSP are established between a sender nodes
which accomodate original servers and all of the leaf nodes which
accomodate broadcast receivers. As same manner, multiple LSP are
established between a sender node which accomodate mirror servers
and leaf nodes.
In this service model, a NWA is introduced to guarantee QoS of video
streaming traffic. A NWA constanly observe residual bandwidth of each
Yasukawa, et. al. [Page 9]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
P2P LSP. Whenever NWA receive request for new video stream, NWA
checks corresponding P2P and judge whether to accept this new session
considering traffic demand.
Because single P2P LSP convey multiple video stream, failure of this
LSP cause severe QoS degradation. Therefore, Fast reroute technology
[FASTREROUTE] is useful to guarantee transimission quality and attain
reliable operation.
Following figure shows one of the example of service sequence for
video on demand service. In this example, a client request CPF of
EPG. After passing authentication, client receive EPG from CPF.
Selecting video channel, client request CPF of encryption decoder key
and video server information (e.g. URL etc). This message is
transffered to NWA. Then NWA judges whether to accept this request
considering server load and corresponding P2P LSP load. After
deciding to accept this request, NWA ask CPF to send back server
information and encryption key to the client. Receiving these
information, the client can control VoD server by RTSP and can
receive video stream data.
+-----+ +-----+
| CPF |<=>| NWA |
+-----+ +-----+
/ / \ \
/ / \ +--------------+
/ / \ \
+------+ +--------+ +--------+ +--------+ +------+
|client|-----| Leaf N |-------|TransitN|-------|Sender N|-----|server|
+------+ +--------+ +--------+ +--------+ +------+
| | | | | | |
|---EPG Req---|>| | | | |
|<--EPG Rep---|-| | | | |
|-Ch.Info.Req-|>| | | | |
| | |-BW Req->| | | |
| | |<BW Rep--| | | |
|<Ch.Info.Rep.|-| | | | |
|-------------|-|---------|----|--- RTSP -------|-------------|
|<============|=|======== |====|=== Video stream =============|
| | | | | | |
Figure 3 sequence example of video on demand service
Yasukawa, et. al. [Page 10]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
3.5 Content Distribution Network architecture
CDN must handle these three type of traffic within a single network
and guarantee QoS of streaming data that are conveyed in both P2MP
LSPs and P2P LSPs at the same time in a scalable, reliable fashion.
Therefore, QoS control, TE and reliability control mechanism
universal to both P2P and P2MP LSP are required. It is desirable that
LSR in this CDN must handle both P2P and P2MP LSP at the same time.
To share network resource flexibly, it is desirable that P2P and P2MP
share same label space. And it is desirable that P2P and P2MP LSPs
are established and maintenanced by same MPLS signaling protocol like
RSVP-TE[RSVP-TE]. It is also desirable to use same Traffic
Engineering Database (TED) for establishing CSPF P2P and P2MP LSPs.
4. Requirements for P2MP capability extension
4.1 P2MP LSP tunnels
A P2MP LSP tunnel MUST be capable of carrying IP multicast traffic.
As conventional P2P MPLS technology[MPLS-ARCH], packets are
classified with FEC in this extension. And all packets which belong
to a particular FEC and which travel from a particular node MUST
follow the same P2MP path. A P2MP LSP MUST handle i) (S,G) multicast
traffic, ii) ({S},G) multicast traffic, and iii) ({S},{G}) multicast
traffic when transfering IP multicast with FEC.
P2MP LSP has different dynamics compared with P2P LSP. Because
destination leaf set changes frequently, it is RECOMMENDED to
introduce a new session key other than destination IP addresses to
identify a P2MP TUNNEL session.
4.2 P2MP LSP topology and Tree explicit routing
Various optimizations in tree formation need to be applied to meet
various needs such as bandwidth guarantees, delay requirements, and
minimization of the total tree cost.
The solution therefore MUST provide a means of establishing arbitrary
trees. Figure 4 shows two typical examples.
Yasukawa, et. al. [Page 11]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
A A
| / \
B B C
| / \ / \
C D E F G
| / \ / \/ \ / \
D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O
Steiner tree SPF tree
Figure 4 Examples of P2MP LSP topology
One example is Steiner tree (Cost minimum tree). This tree is
suitable for constructing cost minimum tree. From several evaluation,
it turns out that steiner tree can reduce one half of necessary
cost[STEINER]. To realize this tree, several intermediate node must
be both MPLS data terminating node and transit node. This means that
the node must perform both label swapping and decapsulation at the
same time.
This extension MUST support a mechanism that can setup terminate
nodes between a sender node and leaf nodes.
Another example is SPF tree. By using delay metric, one can calculate
delay minimum tree. This tree is suitable for carrying real time
traffic.
To control tree toplogy this extension MUST support explicit routing
mechanism [IPMCAST-MPLS] in tree manner. Expanding ERO function to
indicate tree topology is one of this example. It is required that
one can control P2MP tree topoloy any way by using this explicit
routing mechanism.
4.3 Calculation of P2MP path
P2MP path can be computed automatically or can be defined
administratively by a network operator[MPLS-TE]. An administratively
specified path can be completely specified or partially specified.
A P2MP path is completely specified if all of the required branches
and hops between a sender and leaf nodes are indicated. This P2MP
path is calculated by offline management tool or CSPF engine
implemtented in sender node. Considering CSPF calculation at sender
node, it is RECOMMENDED to implement mechanism which can calculate
whole P2MP path using information gathered by an underlying protocol
such as IGP with traffic engineering extensions[OSPF-TE,IS-IS-TE].
Yasukawa, et. al. [Page 12]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
A P2MP path is partially specified if only a subset of intermediate
branches and hops are indicated. This specification include loose
hop. In this case, it is RECOMMENDED to implement mechanism which can
calculate expanded tree using information gathered by an underlying
protocol such as IGP with traffic engineering extensions
[OSPF-TE,IS-IS-TE] in branch node.
4.4 P2MP LSP establishment, teardown, and modification mechanisms
This extension must support large scale P2MP establishment and
teardown in a scalable manner.
In addition to P2MP LSP establishment and teardown mechanism, it
SHOULD implement partial tree modification mechanism. The graft and
prune mechanism can be used to re-establish a partial P2MP LSP when
the establishment of the subtree failed because it sometimes happens
that the establishment of the subtree fails and the establishment of
another part of the tree succeeds. It is inefficient in this
situation for the whole P2MP LSP to be torn down and for the whole
P2MP LSP to be re-established again.
Re-establishment of a subtree whose establishment failed can be done
using the graft and prune mechanism. The sender node or NMS that
recognizes that the establishment of a subtree failed can
re-calculate another P2MP route that avoids the failure point and can
reach the leaf nodes. After this re-calculation, the sender node uses
the graft mechanism for subtree re-establishment and uses the prune
mechanism for subtree elimination. It is RECOMMENDED that this
re-establishment does not cause any additional processing in nodes
except along the path to the failure point, because the graft and
prune process only affects those nodes.
Joining/Leaving mechanism can be considered as part of
Grafting/Pruning mechanism. Adding a leaf LSP to pre-established P2MP
LSP can be considered as a subset of adding a subtree. Vice versa,
deleting a leaf LSP from pre-established P2MP LSP can be considered
as a subset of deleting a subtree.
This extension SHOULD implement subtree Grafting and Pruning
mechanism.
4.5 Management of P2MP LSP tunnels
To identify established topology of P2MP LSP is very important for
management purpose. A network operator uses this information to
manage P2MP LSP. Therefore, topology information MUST be corrected
and updated after P2MP LSP establishment and modification process.
Yasukawa, et. al. [Page 13]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
For this purpose, conventional Record Route mechanism is useful.
As same as conventional mechanism, this information should be
forwarded to the sender node. This extension MUST support a mechanism
which can correct and update tree topology information after P2MP LSP
establishment and modification process. It is RECOMMENDED that those
information are corrected in a data format by which the sendor node
can recoginize tree topology without complicated data calculation
process.
The sender node SHOULD use this information to maintain the tree.
4.6 QoS control mechanism of P2MP LSP tunnels
P2MP LSP share network resource with P2P LSP. Therefore it is
important to use the same QoS control mechanism as P2P LSP for easy
and scalable operation.
This extension MUST support the same QoS indication mechanism as P2P
MPLS. This extension MUST support FF and SE reservation style.
4.7 P2MP TE
Frequent topological changes may occur in a P2MP LSP tunnel because
it has many leaf nodes and a more complex topology. Thus, traffic
engineering is more important in a P2MP network environment than a
P2P one. Traffic Engineering supports rerouting of an established TE
tunnel. The route is decided according to the administrative policy.
The detection of a more optimal path and network resource failure are
examples of situations where path rerouting is needed.
While TE tunnel rerouting is in progress, an important requirement is
avoiding traffic disruption. A useful solution to this problem is the
make-before-break concept. In this concept, traffic passes through
the old path while the new rerouted path is being established. Once
it has been established, traffic is switched to the new path and the
old path is torn down. The make-before-break concept supports
resource sharing of the common part where the old and new path cross.
This sharing is useful to avoid competition between the resources of
the two paths. Details of the make-before-break concept are given in
RFC 3209. In the case of P2MP, there are cases where the
topology of the area to be rerouted is a tree and there are many
paths that should be rerouted when path rerouting occurs at once. So
it is desirable that multiple paths are moved in one rerouting
mechanism.
This extension MUST supports the make-before-break concept for P2MP
TE tunnels. It is deisrable to support local repair mechanism based
on make-before-break but this is a topic for future study.
Yasukawa, et. al. [Page 14]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
4.8 IPv4/IPv6 support
This extension MUST support both IPv4/IPv6 transmission.
4.9 P2P and P2MP LSP establishment
This extension MUST support both P2P and P2MP LSP. The label space
SHOULD be shared between P2P and P2MP MPLS. And link resource SHOULD
be shared between P2P and P2MP MPLS. It is desirable to use same TE
information gathered by IGP with traffic engineering extensions when
CSPF engine calculate P2P and P2MP CSPF path.
4.10 Interworking function with IP multicast
This extension MUST support interworking function with conventional
IP multicast routing protocol such as PIM-SM[PIM-SM].
It is RECOMMENDED to support a message exchange mechanism on top of
P2MP LSP setup mechanism to support multicast (S, G) Join/ Leave and
to allow the sender to hold sufficient information in order to
optimise multicast FEC on sender nodes.
5. Requirements for Service convergence network
5.1 CDN/VoIP/VPN service convergence network
This extension must be applicable to CDN/VoIP/VPN service convergence
network. Applicabilty to VoIP and VPN network is discussed in the
future.
5.2 VPN Multicast
It is RECOMMANDED that this extension must be applicable to VPN
multicast network.
To support VPN multicast, this extension MUST support Multicast
routing information exchange mechanism between PEs. And this
extension MUST support tunneling mechanism of multicast data and
control traffic within a provider network. Detail mechanisms are
discussed in the future.
6. Security Considerations
Security considerations will be addressed in a future revision of
this document.
Yasukawa, et. al. [Page 15]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
7. Acknowledgements
The authors would like to thank George Swallow for his review and
suggestion of an earlier draft of this document.
8. References
[DJIKSTRA] E. W. Djikstra, "A note on two problem in connection with
graphs," Numerische Mathematik, vol.1, pp.269-271, 1959
[IGAP] T. Hayashi, D. Andou, H. He, W. Tawbi, T. Niki, "IGAP for user
Authentication Protocol (IGAP)", draft-hayashi-igap-00.txt,
January 2003
[STEINER] H. Salama, et al., "Evaluation of Multicast Routing
Algorithm for Real-Time Communication on High-Speed Networks,"
IEEE Journal on Selected Area in Communications, pp.332-345, 1997
[FASTREROUTE] P. Pan, D. Gan, G. Swallow, J. P. Vasseur, D. Cooper,
A. Atlas, M. Jork,"Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt, May 2003
[RSVP-TE] D. Awduche., L. Berger., D. Gan., T. Li., V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209,
December 2001
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[IGMPv2] W. Fenner, "Internet Group Management Protocol, IGMP,
version 2", RFC 2236, November 1997.
[IGMPv3] Cain, B., "Internet Group Management Protocol,
Version 3", draft-ietf-idmr-igmp-v3-11.txt, May 2002
[PIM-SM] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification.",
RFC 2362, June 1998.
[MPLS-TE] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering Over MPLS", RFC2702,
September 1999
[OSPF-TE] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-08.txt,
September 2002
Yasukawa, et. al. [Page 16]
Internet Draftdraft-yasukawa-mpls-p2mp-requirement-00.txt Feburarly 2003
[IS-IS-TE] Henk Smit, Tony Li, "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-04.txt, December 2002
[IPMCAST-MPLS] D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul
and F. Ansari, "Overview of IP Multicast in a Multi-Protocol Label
Switching (MPLS) Environment", RFC3353, August 2002.
9. Author's Addresses
Seisho Yasukawa
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Ichiro Inoue
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 6076
EMail: inoue.ichiro@lab.ntt.co.jp
Yasukawa, et. al. [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 19:07:59 |