Internet Engineering Task Force Liming Wei INTERNET-DRAFT Naiming Shen draft-wei-rmr-00.txt Tom Meehan Redback Networks October 2003 Expires April 2004 Remote Multicast Replication (RMR) Protocol 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Distribution of this document is unlimited. Abstract The deployment and provisioning of multicast services must satisfy certain network design constraints in the last mile. It is common for a network design to have a small set of intelligent layer 3 devices (controllers) and a larger set of simpler layer 2 devices (aggregators). The controllers handle routing, user authentication and access control etc. They are connected via a network to the aggregators closer to the clients. Special design is needed to support multicast over this network. This draft proposes a Remote Multicast Replication (RMR) protocol, that reduces or removes duplicate multicast traffic in between the controllers and the aggregators. The RMR protocol is independent of layer 2 technology and topology being used. Wei, Shen, et all Expeires April 2004 [Page 1] INTERNET DRAFT RMR Protocol October 2003 1. Introduction IP multicast is believed to be a service enabler for video or TV over IP applications. The deployment or provisioning of these services must satisfy certain network design constraints. One common network design is to put all the intelligence in a smaller set of devices, such as a GGSN [1] device (controller), and traffic aggregation or grooming capabilities in a larger number of more geographically distributed devices (client aggregators), such as the SGSNs [1]. When multicast is introduced, the network bandwidth utilization is improved in all part of the network, except in between the controllers and the aggregators. This draft specifies the Remote Multicast Replication (RMR) protocol, that reduces or removes duplicate multicast traffic in between the controllers and the aggregators. RMR employs a few dedicated messages for the controllers to inform or update the aggregators about changes in multicast forwarding state for each client. It allows the aggregator to replicate from a single incoming multicast packet stream to all its clients that need a copy of that stream. By supporting RMR, the aggregators can perform multicast replications, without supporting any routing functions, or user authentication, billing functions. In the following text, an aggregator is also referred to as a replicator. 2. Background The need to perform remote replications exists in a wide range of networks, including GPRS wireless networks across GTP (GPRS tunneling protocol) tunnels [1], bandwidth wholesale networks between the LNS and LAC of a l2tp tunnel [2], or between a BRAS (broadband remote access server) and the DSLAMs (Digital Subscriber Line Access Modules) [3], etc. Instead of designing similar mechanisms differently for each of these scenarios and add similar extensions to each of those protocols, we propose RMR as a generic mechanism. This reduces the duplicate efforts in designing and debugging similar functions in different protocols, and preserves the investment in implementation and deployment across technology upgrades. RMR decouples multicast remote replication from the layer two technology, allowing significant flexibility in network design. For example, in an L2TP setup, an operator can optionally direct unicast traffic through an L2TP tunnel and multicast sessions through GRE tunnels over a different physical interface to the replicators. Such flexibility allows a network provider to optimize the multicast distribution paths and better utilize the existing network. There is little restriction on where or over which path the multicast sources have to be injected into the network. Wei, Shen, et all Expeires April 2004 [Page 2] INTERNET DRAFT RMR Protocol October 2003 RMR does not require the aggregators to be IP routing devices, which avoids hugh increases in the number of managed routing devices. This helps to scale network routing, and keep the core network more stable. 3. Remote Multicast Replication (RMR) Protocol In describing the RMR protocol, we refer to the control device, often a multicast router, as the Multicast Controller (MC); and the remote client aggregation device replicating traffic, the Multicast Replicator (MR). Access line termination Multicast replication Authentication +-----+.... access control .-| MR1 |.... To clients routing etc / +-----+ +----+ / +-----+.... ---| MC |--(layer 2/3 network) ---+----| MR1 |.... +----+ \ +-----+ \ ..... \ +-----+.... \.________| MRn |.... +-----+ Figure 1. Typical network topology for RMR application Figure 1 shows a typical topology for RMR applications. The MC is usually an IP capable device, performing routing, user authentication, access control, and billing functions. The MRs are lower cost layer 2 devices, capable of multicast replication and other minimal IP level functions. For network access control reasons, the clients can not talk directly to each other, and must go through the MC. The MC is usually connected to the MR's via a layer 2 or 3 network. We assume the MC runs IGMP [4, 5] and PIM [6]. Each MR will have an administratively assigned ID, by which the MC can use to address it. An IGMP report originated by a client is passed through its MR and received by the MC. The MC learns a unique identifier about this client. This could be the MAC address of the client, or another identifier in the IGMP packet encapsulation header. The MC validates this IGMP report, possibly through its network policy management component. If this IGMP report is accepted, the MC sends a RMR Port Announcement (PA) message toward the MRs. The PA message contains the following information: Wei, Shen, et all Expeires April 2004 [Page 3] INTERNET DRAFT RMR Protocol October 2003 1) The user ID that the MR can identify the client with; 2) The multicast group address, or (source, group) address pair the client needs to join; 3) The IP address of the MC. A MR receives a PA message, checks if the user ID belongs to one of its clients. If there is no match, the PA message is discarded silently. If a match is found, the PA message is destined to this MR. The MR translates the user ID into the physical port ID the client is connected to, and populates that port in the corresponding multicast replication entry. After a MR completes processing a PA message destined to it, it sends a PA Acknowledgement (PAA) message to the MC. The PAA message contains all information in the PA message, plus the MR's ID, and the port ID. The PAA also tells the MC whether it was capable of performing the operation requested by the PA message. If the MC is on the multicast forwarding path, the MC adds the interface toward the MR to its (*,G) or (s,G) forwarding entry's outgoing interface list. When this stage is completed, multicast traffic will be multicast transmitted by the MC to each MR with members, and replicated to all clients by their MRs. Notice that the MC's outgoing interface may not be the same interface where the IGMP report is received for that user. As an optimization, the MC can maintain the mapping between the client's ID and the MR's ID. Subsequent PA messages will only need to be sent directly to the specific MR . When an IGMP leave is received by the MC from the last client on a MR port, the MC sends a PA message to the MR, with the same set of information that was sent when it joined, except one bit field to signal the removal of the MR port from its multicast replication table. While awaiting a PAA response message from a MR, the MC should retransmit the PA message in a predetermined interval. It should consider the request failed if a predetermined maximum number of retries were done and no response is received from a MR. When a PA message is not positively acknowledged, the MC should update its client's accounting record for such failure, or trigger alarms. No further RMR actions will be performed to "fix" such a failure. 4. Message format RMR messages are encoded inside UDP over IPv4, destined to well-known port number RMR-PORT (to be assigned by IANA). The Wei, Shen, et all Expeires April 2004 [Page 4] INTERNET DRAFT RMR Protocol October 2003 messages are encoded in a type-length-value (TLV) fashion. Multiple TLVs can be packed into the same UDP packet. Each TLV can also optionally contain multiple sub-TLVs: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Message fields ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type Length Total Message Length Message fields Message fields. The currently defined message type values are: 0 - 16 reserved. 17 Port Announcement message. 18 Port Announcement Acknowledgement message. 19 Authentication message. 4.1 RMR Port Announcement (PA) Message A Multicast Controller uses a PA message to inform a Multicast Replicator to add or delete a client port from a multicast replication entry. The 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 17 | Length (x+12) | Reserved |a| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UID (length x) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Length of the entire message. I.e. x+12, where x is the UID's length. Reserved Set to 0 on transmission. Ignored on reception. a 1 Request is to add client port to replication table. 0 Request is to delete client port. Group IP multicast Group address Source Source address UID User ID sub-TLV. Wei, Shen, et all Expeires April 2004 [Page 5] INTERNET DRAFT RMR Protocol October 2003 4.2 RMR Port Announcement Acknowledgement (PAA) Message A Multicast Controller sends this message to a Multicast Controller, in response to a Port Announcement message destined to it. This message is unicast addressed to the Multicast Controller. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | Length(x+y+12)| Reserved |r|a| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UID (length x) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DevID (length y) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Length of the entire message. I.e. x+y+12, where x is the UID's length and y is the DevID's length. Reserved Set to 0 on transmission. Ignored on reception. a 1 Request is to add client port to replication table. 0 Request is to delete client port. r Result. 1 requested action is performed successfully. 0 requested action is not performed. Group IP multicast Group address Source Source address UID User ID sub-TLV. DevID MR device ID sub-TLV. 4.3 User ID sub-TLV. A User ID is a sub-TLV which is embedded inside the PA and PAA messages. It 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UID Code 1 | Length | UID Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wei, Shen, et all Expeires April 2004 [Page 6] INTERNET DRAFT RMR Protocol October 2003 The sub-TLV code of UID is 1. The length depends on the UID type. The Reserved field is set to 0 on transmission, ignored on reception. The currently defined UID type values are: 0-16 Reserved. 17 IEEE802 MAC address. Length is set to 10. The Value portion is 6 bytes MAC address. 18 ATM PVC. Length is set to 36. With 32 bits for VCID, followed by 16 bits of VPI, and 16 bits of VCI. 19 Frame Relay DLCI. Length is set to 10. With 32 bits for VCID, followed by 16 bits of DLCI. 20 GTP TID. Length is set to 12. The Value portion is 8 bytes TID. 21 L2TP Session ID. Length is set to 8. The Value portion is 4 bytes L2TP session ID. 22-255 For future use. 4.4 Device ID sub-TLV A Device ID is a sub-TLV which is embedded inside the PAA message. It 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DevID Code 2 | Length | DevID Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device ID Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sub-TLV code of DevID is 2. The length depends on the DevID type. The Reserved field is set to 0 on transmission, ignored on reception. The currently defined DevID type values are: 0-16 Reserved. 17 Generic Device Type, the length is set to 20, which is defined in the following format, each of the field if unused should be set to 0: 4 bytes of device number(e.g. can be a IPv4 router ID), 2 bytes of virtual device number(e.g. can be a virtual router ID), 2 bytes of slot number, 4 bytes of port number, 4 bytes of sub-port number 18-255 For future use. 4.5 Authentication TLV An optional authentication mechanism can be used with RMR protocol packets. When the authentication is enabled on the RMR, the sender Wei, Shen, et all Expeires April 2004 [Page 7] INTERNET DRAFT RMR Protocol October 2003 needs to include this authentication TLV in the packet. If the authentication is enabled for the RMR, the receiver needs to check all the inbound RMR packets for this authentication TLV, the packet MUST be discarded if the authentication TLV is missing or the authentication value does not match the one defined locally. The authentication 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 | Length | Auth-type | Key-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication-Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type 19 Length Length of the message, 4 + length of the Authentication-Value field Auth-type 1, Simple password mechanism 2, MD-5 authentication mechanism Key-id A number in the range of 0-255 to uniquely identify the MD-5 key used in the packet. In the case of simple password mechanism or single MD-5 key being used, this Key-id should be set to 0 by the sender, and ignored by the receiver. Authentication- This is either a simple password string if the Value Auth-type is 1, or a 16 byte MD-5 Key if the Auth-type is 2. When the authentication type is MD-5 [7], the algorithm requires a key K and text T as input. The key K is the password for the MD-5 scheme, and the text T is all the RMR messages in the packet to be authenticated with the Authentication-Value field inside this Authentication TLV set to zero. This text T does not include IP and UDP headers. Note that the Authentication Type is set to 2, and the Length is set to 20 and the Key-id is set to the desired value before the authentication is computed. The result of the algorithm is placed in the Authentication-Value field. 5. Security Considerations The RMR protocol has the authentication message defined, the use of MD-5 authentication mechanism is strongly recommended if the network security is a concern. The authentication mechanism described in section 4.5 can be applied to reduce the risk of unauthorized source injecting false information into the remote multicast replication system. Wei, Shen, et all Expeires April 2004 [Page 8] INTERNET DRAFT RMR Protocol October 2003 6. Acknowledgments TBD. 7. Intellectual Property Considerations Redback Networks may have intellectual property rights claimed in regard to some of the specification contained in this document. 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. References [1] ETSI EN 301 347: "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (GSM 09.60 version 7.5.1 Release 1998)". [2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunneling Protocol "L2TP" ", RFC2661, August 1999. Wei, Shen, et all Expeires April 2004 [Page 9] INTERNET DRAFT RMR Protocol October 2003 [3] DSL Forum WT-081, "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", March 2003. [4] Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, November 1997. [5] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group Management Protocol, Version 3," RFC 3376, October 2002. [6] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 10. Author's Addresses Liming Wei Redback Networks 300 Holger Way San Jose, CA 95134 lwei@redback.com Naiming Shen Redback Networks 300 Holger Way San Jose, CA 95134 naiming@redback.com Tom Meehan Redback Networks 300 Holger Way San Jose, CA 95134 tmeehan@redback.com Wei, Shen, et all Expeires April 2004 [Page 10]