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 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->| | | | | | |