Network Working Group YouSong Internet-Draft FiberHome Networks Expires February 2002 Reinaldo Penno NortelNetworks August, 2001 IP multicasting and broadcasting extension for PPPoE Protocol draft-song-pppoe-ext-multicast-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. This document is an Internet Draft. 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 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 a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In the year following the publication of the PPPoE protocol much operational experience and customer feedback was gathered. One problem that access providers usually mention is that when PPPoE Server needs to send IP multicast packets or broadcast packets to PPPoE Clients in a same Ethernet, it has to send these packets to each PPPoE Client over each PPPoE link. Because the PPPoE Clients are all in a Ethernet, this multiplication of packets affects performance and wastes the net's resource. We propose here a method to transmit broadcast and multicast packets in PPPoE networks. Specification of Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [3]. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . .2 2. Protocol Content. . . . . . . . . . . . . . . . . . . . . .2 3. Applicability Scenarios. . . . . . . . . . . . . . . . . . 4 4. References. . . . . . . . . . . . . . . . . . . . . . . . .6 5. Author's Addresses. . . . . . . . . . . . . . . . . . . . .6 Full Copyright Statement. . . . . . . . . . . . . . . . . .6 YouSong, et al. [Page 1] Internet-Draft draft-song-pppoe-ext-multicast August, 2001 1. Introduction This document define a method to increase the performance of the IP multicasting and broadcasting in PPPoE links. PPP over Ethernet (PPPoE) provides the ability to connect a network of hosts (PPPoE Client) over a simple bridging access device to a remote Access Concentrator(PPPoE Server). With this model, each host utilizes it's own PPP stack and the user is presented with a familiar user interface. Access control, billing and type of service can be done on a per-user, rather than a per-site, basis. But when PPPoE Server needs to send IP multicast packets or broadcast packets to PPPoE Clients in a same Ethernet, it has to send these packets to each PPPoE Client over each PPPoE link, because the PPPoE Clients are all in a Ethernet, so its performance is bad and wastes the net's resource. 2. Protocol content PPPoE is a method to transmit PPP packets over Ethernet, it dummy many PPP connections, and it is an access technique. Its merit is to utilize the Ethernet's convenience and to utilize the PPP's point- to-point attribute, so it can manage each connection and can use PPP protocol's authentication protocol(CHAP,PAP) function and the function of IPCP's assigning IP address to each user dynamically, and PPP's Encryption function, therefore the PPPoE is being used more and more. But PPPoE supports IP multicasting and broadcasting inefficiently, it is necessary to describe the PPPoE's communication process here. There are two phases in PPPoE protocol, Discovery stage and PPP Session stage. During the Discovery stage, the PPPoE client(usual a PC host) sends a broadcast Ethernet frame which is called PADI in PPPoE protocol over the Ethernet to ask PPPoE server to reply, if there is a PPPoE server which can satisfy the client's request in the Ethernet,it will reply a PADO frame to the client, this frame is a unicast Ethernet frame. Then the client selects a PPPoE server among the PPPoE servers which have sent a PADO packet to the client, and the client sends a unicast Ethernet frame(PADR) to the server to show that the client wants to establish a PPPoE Link with the server ,and if the server agrees with the request, the server sends a unicast Ethernet frame(PADS) to the client and assigns a session identification for the client, and the Discovery stage ends. During the PPP Session stage, the PPPoE server and the PPPoE client will send PPP packets in the link to establish a PPP connection and transmit IP packets over the connection, all the frames in this stage are unicast frames. So If the PPPoE server will send a IP multicast packet to the clients, it has to send the packet to each client over each PPPoE link, and this goes against the purpose of IP multicasting over Ethernet. YouSong, et al. [Page 2] Internet-Draft draft-song-pppoe-ext-multicast August, 2001 Below the document will describe the PPPoE frame and PPPoE's payload, then describe the modification to PPPoE protocol. An Ethernet frame is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DESTINATION_ADDR | | (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SOURCE_ADDR | | (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ payload ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ETHER_TYPE field is set to 0x8863 or 0x8864 to PPPoE Protocol. The Ethernet payload for PPPoE is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER | TYPE | CODE | SESSION_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LENGTH | payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The modification to PPPoE is: A. When a PPPoE node will send out a IP broadcast data packet,set the Ethernet frame's DESTINATION_ADDR value to 0xFFFFFFFFFFFF, set the Ethernet frame's ETHER_TYPE to 0x8864. And a PPPoE node will accept this broadcast packet when the ether_type value is 0x8864 and the dest mac is 0xFFFFFFFFFFFF. YouSong, et al. [Page 3] Internet-Draft draft-song-pppoe-ext-multicast August, 2001 B. When a PPPoE node will send out a IP multicast data packet, according to RFC1112 to set the Ethernet frame's destination mac address,i.e., place the low-order 23-bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E -00-00-00 (hex),set the thernet frame's ETHER_TYPE to 0x8864. And if a PPPoE node has joined this group,it will accept this packet. This document doesn't ask this method to be applied to multicast protocols, for example, this document asks the IGMP Messages to be sent out in PPPoE Links according to RFC2516(PPPoE), so when a PPPoE client joining a group, it will send a IGMP Member report message in its PPPoE link, and so The PPPoE server can know which PPPoE clients have joined a multicast group, when the PPPoE Server sending out a IP multicast data packet by using the way which is describing in this document, it can increase the received packets counters for the PPPoE links which have joined the group, this is meaningful to bill the PPPoE clients. C. When a PPPoE client joining a ip multicast group, it must call the operation "JoinLocalGroup ( group-address )" which is described in the section 7.3 in RFC1112(Host Extensions for IP Multicasting) to let the Ethernet local network module to receive the multicast packets belong to the group; When a PPPoE client leaving a ip multicast group, it must call the operation " LeaveLocalGroup ( group-address )" to let the Ethernet local network module not to receive the multicast packets anymore. D. If a PPPoE client supports the multicasting method which is described in this document, set the TYPE field to 0x2 when sending out a IGMP Member Report message. If a PPPoE client sent a IGMP Member Report message with type field value to 0x1,then PPPoE server will have to send the group's multicast packets to this client according to RFC2516(PPPoE). If a PPPoE client sent a IGMP Member report message with type field value to 0x2,then PPPoE server will send the group's multicast packets according to this document. E. Set the SESSION_ID value to 0xffff to show that the packet is not for a single PPPoE link when a PPPoE node sending out a ip broadcast packet or ip multicast packet in the way described in this document. 3. Applicability Scenarios 3.1 Metro Ethernet Networks In this scenario, also called FTTH (Fiber to the Home), the user connects his PC directly to a Ethernet switch through a Ethernet port on his home. YouSong, et al. [Page 4] Internet-Draft draft-song-pppoe-ext-multicast August, 2001 User A \ \->|----| | PC |\ |--------| |--------| |----| /->|----| \-|Ethernet| |Ethernet| | AC | / | Switch |-->Access-->| Switch |------>| | User B |----| /-|--------| Network |--------| |----| | PC |/ |----| Since this model basically follow Ethernet standards, the AC needs to send only one multicast packet for each Ethernet Switch attached to it. "This definitely needs to be expanded to discuss IGMP Proxy or Snooping on the switch. Bandwidth savings could be even greater." "We also need to discuss when 802.1Q VLANS are used. This is really important" 3.2 Cable Modem Access Networks Cable modem access is a technology to provide high speed Internet access over the Cable TV infrastructure. User A \ \->|----| | PC |\ |------| |------| |----| /->|----| \-|Cable | | | | AC | / |Modem |-->Access-->| CMTS |------>| | User B |----| /-|------| Network | | |----| | PC |/ |------| |----| In this model the access network must pass the packets transparently between the cable modem and the edge device, since a layer 2 end-to-end session (PPPoE) must be established between the user and the AC. Since the network behind a CMTS works like a broadcast medium, the YouSong, et al. [Page 5] Internet-Draft draft-song-pppoe-ext-multicast August, 2001 AC needs to send only one multicast packet for each CMTS attached to it. Since behind a CMTS there are usually hundreds of cable modems and respective PCs potentially receiving multicast traffic from a specific group, it can be seen that the bandwidth savings are considerable 3.3 Digital Subscriber Line Access Networks Digital Subscriber Line (DSL) is a technology used to supply high-bandwidth connectivity over ordinary copper telephone lines. xDSL represents the family of digital subscriber line technologies, such as ADSL, HDSL and SDSL. The figure below depicts a typical xDSL deployment User A \ \->|----| | PC |\ |------| |------| |----| /->|----| \-|xDSL | | | | AC | / |Modem |-->Access-->|DSLAM |------>| | User B |----| /-|------| Network | | |----| | PC |/ |------| |----| In this scenario, since the AC has a different ATM VC to each modem, it has to make a copy of each multicast packet to each VC that has at least of PC subscribed to a specific group. We can see then that most of the advantages of this extension to this type of scenario comes when there are several PCs with PPPoE clients behind a single modem. 4. References [1] L. Mamakos, "A Method for Transmitting PPP Over Ethernet (PPPoE)" RFC2516, February 1999. [2] S. Deering, "Host Extensions for IP Multicasting" ,August 1989. YouSong, et al. [Page 6] Internet-Draft draft-song-pppoe-ext-multicast August, 2001 Authors' Addresses You Song, FiberHome Networks Inc. 88,YouKeyuan lu,Hongshan District,Wuhan,Hubei Prov., P.R.China 430074 Email: syou@wri.com.cn Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society.