Network Working Group WL. Cao Internet-Draft ZTE Corporation Intended status: Informational BS. Zhang Expires: October 10, 2007 ZTE Corporation April 3, 2007 PPP Over Ethernet (PPPoE) Extensions for IP multicast and broadcast draft-caowenli-pppoe-multicast-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on October 10, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document extends the Point-to-Point Over Ethernet (PPPoE) Protocol [2] with a forwarding mode for IP multicast packets or broadcast packets in PPPoE networks. This optional extension can improve the performance of the IP multicasting and broadcasting in PPPoE links. Cao, Zhang Expires October 10, 2007 [Page 1] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 Table of Contents 1. Requirements notation ........................................3 2. Introduction..................................................4 3. Overview of Protocol Extensions...............................4 4. Discovery Stage...............................................7 4.1 PPPoE Active Discovery Initiation (PADI)..................7 4.2 PPPoE Active Discovery Offer (PADO).......................7 4.3 PPPoE Active Discovery Request (PADR).....................8 4.4 PPPoE Active Discovery Session-confirmation (PADS)........8 5. PPP Session Stage.............................................9 6. Other Considerations..........................................9 7. IANA Considerations...........................................9 8. Security Considerations.......................................9 9. Appendix A: Tag Values.......................................10 11. Appendix B: Example Message Formats.........................11 12. Acknowledgements............................................12 13. Normative References........................................12 Authors' Addresses..............................................12 Intellectual Property and Copyright Statements..................13 Cao, Zhang Expires October 10, 2007 [Page 2] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 1. Requirements notation 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 [5]. Cao, Zhang Expires October 10, 2007 [Page 3] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 2. Introduction 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). There are two phases in PPPoE protocol, Discovery stage and PPP Session stage. When the Discovery stage completes, both peers know the PPPoE SESSION_ID and the peer's Ethernet address. During the PPP Session stage, All Ethernet packets are unicast. So when Access Concentrator needs to send IP multicast packets or broadcast packets to Hosts in a same Ethernet, it has to send these packets to each host over each PPPoE link, because the hosts are all in a Ethernet, so its performance is bad and wastes the net's resource. This document define a forwarding mode for IP multicast packets or broadcast packets to increase the performance of the IP multicasting and broadcasting in PPPoE links. These extensions to PPPoE are optional and preserve compatibility. 3. Overview of Protocol Extensions PPPoE has two distinct stages. There is a Discovery Stage and a PPP Session Stage. During the Discovery Stage, the host can optionally request a forwarding mode for IP multicast packets or broadcast packets controlled PPP Session Stage. Once the Access Concentrator acknowledges the host forwarding mode request, all IP multicast packets or broadcast packets during PPP Session Stage must be forwarded according to the negotiated forwaring mode. The forwaring mode is described below. IP multicast packets or broadcast packets during PPP Session Stage must be forwarded in a PPPoE encapsulation according to the existing PPPoE protocol. The extensions described in this document allow these packets be forwarded in the other encapsulations. These extended encapsulations are described as follows. IP multicast packets are partitioned two sorts of packets: protocol packets (e.g. IGMP/MLD packet) and bearer data packets (i.e. mulitcast flow). These two kinds of multicast packets and broadcast packets can be all forwarded in the following encapsulations. A. PPPoE It means these packets are forwarded in the existing PPPoE encapsulation during PPP Session Stage. This case is compliant to the existing PPPoE protocol. Cao, Zhang Expires October 10, 2007 [Page 4] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 B. IPoE It means these packets are forwarded in the IPoE encapsulation during PPP Session Stage. For broadcast packets, This encapsulation only denotes that Access Concentrator can send broadcast packets encapsulated in IPoE and the host can receive the corresponding broadcast packets encapsulated in IPoE, and that the host can't send broadcast packets encapsulated in IPoE associated the PPPoE sessions, it can send broadcast packets encapsulated in PPPoE associated the PPPoE sessions. In addition, multicast protocol packets can be forwarded in another encapsulation. This encapsulation is PPPoE and IPoE. It means multicast protocol packets are forwarded as both PPPoE as well as IPoE packets to the network during PPP Session Stage, that is, a multicast protocol packet is sent twice, it is forwarded in a PPPoE encapsulation for the first time, then it is forwarded in a IPoE encapsulation once more. There is only one combination of the above encapsulations for forwarding multicast packets during a PPPoE session. A. Forwarding multicast protocol packets encapsulated in PPPoE, forwarding multicast bearer data packets encapsulated in IPoE. In this case, multicast protocol packets are asked to be forwarded in PPPoE Links according to RFC2516(PPPoE), so multicast access controls on per subscriber basis can be provided by observing the IGMP/MLD report packets, and multicast group keepalive mechanism on per subscriber basis and per multicast group basis can be also achieved by utilizing the IGMP/MLD query and report packets in a PPPoE link, this keepalive mechanism can be used to detect which multicast groups the hosts have currently joined and how long the hosts have joined them, this is meaningful to accurately bill the hosts. Multicast bearer data packets are forwarded in a IPoE encapsulation, this mode is the same as the existing IP multicast implementation. PPPoE multicast functionality is optimized by efficient replication as IPoE multicast. When multicast packets are forwarded in this way, the intermediate (L2) device between hosts and Access Concentrator need support IGMP or MLD snooping/proxy [3][4] within the PPPoE session for establishment of multicast forwarding entries, or the multicast forwarding entries in the intermediate devices are Cao, Zhang Expires October 10, 2007 [Page 5] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 provided by PPPoE Access Concentrator making use of other dynamic protocols or management system. B. Forwarding multicast protocol packets encapsulated in PPPoE and IPoE, forwarding multicast bearer data packets encapsulated in IPoE. The description is the same as the previous section except the following. In this case, a multicast protocol packet is forwarded as both PPPoE as well as IPoE packets. The IPoE encapsulated multicast protocol packet can be used to achieving IGMP or MLD snooping/proxy function by the the intermediate device between hosts and Access Concentrator, and then the the existing IP multicast implementation of the intermediate device remain unchanged to ensure inter-operability. A multicast protocol packet is received in both the IPoE encapsulation as well as the PPPoE session by both PPPoE peers, and therefore both peers should check whether the both encapsulatin multicast protocol packet is the same by matching the source address, use the multicast protocol packets from the PPPoE session to correlate to the appropriate multicast bearer data packets encapsulated in IPoE. Once again, this source address may be a IP/MAC address. C. Forwarding multicast protocol packets encapsulated in PPPoE, forwarding multicast bearer data packets encapsulated in PPPoE. The forwarding mode for PPPoE multicast packets is the same as the existing PPPoE multicast implementation in this case. D. Forwarding multicast protocol packets encapsulated in IPoE, forwarding multicast bearer data packets encapsulated in IPoE. The forwarding mode for PPPoE multicast packets is the same as the existing IP multicast implementation in this case. PPPoE multicast functionality is optimized by efficient replication as IPoE multicast. E. Other combinations. Other combinations aren't meaningful. In addition, there are only one combination of the above encapsulations for broadcast packets during a PPPoE session. Cao, Zhang Expires October 10, 2007 [Page 6] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 A. Forward broadcast packets encapsulated in PPPoE. The forwarding mode for PPPoE broadcast packets is the same as the existing PPPoE broadcast implementation in this case. B. Forward broadcast packets encapsulated in IPoE. The forwarding mode for PPPoE broadcast packets is the same as the existing IP broadcast implementation in this case. PPPoE broadcast functionality is optimized by efficient replication as IPoE broadcast. 4. Discovery Stage The packet exchange of the Discovery Stage is unchanged by this specification. The specifications of the PADI, PADO, PADR and PADS packets are extended to include the optional forwarding Tag Type-Length-Value (TLV). 4.1 PPPoE Active Discovery Initiation (PADI) The PADI packet is extended to optionally contain several Forward-Mode Tag TLVs, indicating that the host requests forwarding control for this session when forwarding multicast packets or broadcast packets. 4.2 PPPoE Active Discovery Offer (PADO) The PADO packet is extended to optionally contain several Forward-Mode Tag TLVs, indicating the forwarding mode supported by Access Concentrator for multicast packets or broadcast packets during the PPP Session Stage. Access Concentrator may perform one of the following actions if it supports the negotiation for the forwarding mode described in this document. A. Access Concentrator optionally contain several Forward-Mode Tag TLVs supported by itself , and any number of other TAG types. B. Access Concentrator optionally only contain the requested Forward-Mode Tag TLVs by the host and supported by itself , and any number of other TAG types. To ensure inter-operability, Access Concentrator MAY silently ignore the TAGs in PADI if it does't supports the negotiation for the forwarding mode described in this document. Cao, Zhang Expires October 10, 2007 [Page 7] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 4.3 PPPoE Active Discovery Request (PADR) Access Concentrator The PADR packet is extended to optionally contain several Forward-Mode Tag TLVs, indicating that the host requests forwarding control for this session when forwarding multicast packets or broadcast packets. The host may perform one of the following actions if it supports the negotiation for the forwarding mode described in this document. A. If the PADO contains Forward-Mode Tags that host is requesting, then the host can choose the forwarding mode the host is requesting, The PADR packet should contain Forward-Mode TAGs the host is requesting. B. If the PADO does't contains Forward-Mode Tags that host is requesting, then The PADR packet does't contain any Forward-Mode TAGs. To ensure inter-operability, host MAY silently ignore the TAGs in PADO if it does't supports the negotiation for the forwarding mode described in this document. An example packet is shown in Appendix B. 4.4 PPPoE Active Discovery Session-confirmation (PADS) The PADS packet is extended to optionally contain several Forward-Mode Tag TLVs, indicating the forwarding mode supported by Access Concentrator for multicast packets or broadcast packets of the PPP Session Stage. If the PADR contains Forward-Mode Tags, then the Access Concentrator PADS packet indicates support for forwarding control by including Forward-Mode Tags. The PADS Forward-Mode Tags indicate the forwarding mode under which Access Concentrator has accepted the PPPoE session. Exchange of the Forward-Mode Tag TLVs in the Discovery packets indicates that forwarding control is supported by both the Access Concentrator and the host for the designated PPP Session Stage. This is binding and must be followed for the entire duration of the PPP Session Stage. The Access Concentrator PADS should only carry the Forward-Mode Tags in response to a host PADR with Forward-Mode tags. If the Access Concentrator does not support the forwarding modes requested, it must not include the Forward-Mode Tags in its PADS response. Cao, Zhang Expires October 10, 2007 [Page 8] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 When the host receives the PADS containing the Forward-Mode tags it is requesting, then the host must forward packets by the forwarding mode supported by both the host and the Access Concentrator. When the host receives the PADS that it does't contain the Forward-Mode tags it is requesting, then the host must forward packets by the default forwarding mode, i.e. PPPoE mode. An example packet is shown in Appendix B. 5. PPP Session Stage Multicast packets or broadcast packets are forwarded in the negotiated forwarding mode by both PPPoE peers during the PPP Session Stage. Other packets are forwarded in the existing PPPoE encapsulation. 6. Other Considerations Note that this PPPoE Extension does not consider optimizing multicast delivery over PPPoA and other PPPoX sessions and therefore those scenarios are not considered. "This definitely needs to be expanded to discuss PPP NCP [1] Extension for IP multicast and broadcast." 7. IANA Considerations This document proposes a PPPoE tag to be maintained by the IANA. The tag Forward-Mode may be assigned the values 0x0122 so as not to conflict with the defintions for recognized PPPoE tags, as defined in RFC 2516 [2]. 8. Security Considerations This memo defines a mode for forwarding control to the existing PPP Over Ethernet (PPPoE) sessions. These extensions are subsequent to the existing PPPoE security mechanisms as described in RFC 2516 [2]. Cao, Zhang Expires October 10, 2007 [Page 9] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 9. Appendix A: Tag Values Feature Tag_Types and Tag_Values 0x0122 Forward-Mode This tag contains the Forwarded Packet Type(FPT) and the Forwarding Encapsulation(FE). The Forward-Mode Tag TLV is OPTIONAL with the PADI, PADO, PADR and PADS, and can be contained more than one in a Discovery packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Type = 0x0122 | Tag Length=0x04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarded Packet Type(FPT) | Forwarding Encapsulation(FE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Forwarded Packet Type field is one octet, and Values for this field are assigned as follows: Value Forwarded Packet Type 1 multicast protocol packets 2 multicast bearer data packets 3 broadcast packets The Forwarding Encapsulation field is one octet, and Values for this field are assigned as follows: Value Forwarding Encapsulation 1 PPPoE 2 IPoE 3 PPPoE and IPoE When FPT value is 1, the FE value can be set to 1, 2, or 3. When FPT value is 2 or 3, the FE value can be set to 1 or 2. Cao, Zhang Expires October 10, 2007 [Page 10] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 10. Appendix B: Example Message Formats A PADR packet with OPTIONAL Forward-Mode Tag Type 0x0122: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access_Concentrator_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Access_Concentrator_mac_addr(c)| Host_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host_mac_addr (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SESSION_ID = 0x1234 | LENGTH = 0x0C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Type = 0x0101 | Tag Length=0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Type = 0x0122 | Tag Length=0x04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarded Packet Type | Forwarding Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A PADS packet with OPTIONAL Forward-Mode Tag Type 0x0122: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access_Concentrator_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Access_Concentrator_mac_addr(c)| Host_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host_mac_addr (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x65 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SESSION_ID = 0x1234 | LENGTH = 0x0C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Type = 0x0101 | Tag Length=0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Type = 0x0122 | Tag Length=0x04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarded Packet Type | Forwarding Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cao, Zhang Expires October 10, 2007 [Page 11] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 11. Acknowledgements The authors would like to acknowledge the influence and contributions from Zhang Boshan, Yuan Liquan, Zhang Weiliang and Zhu Songlin. 12. Normative References [1] G. McGregor., Editor, "The PPP Internet Protocol Control Protocol (IPCP).", RFC 1332, May 1992 [2] Mamakos L., et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [3] Christensen, et al., "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [4] Fenner, et al., "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Address Cao Wenli (WL. Cao) ZTE Corporation E4083, 889 Bilo Road, Zhangjiang Hi-TechPark, Pudong, Shanghai, P.R.China 201203 P.R.China email: cao.wenli@zte.com.cn Zhang Boshan (BS. Zhang) ZTE Corporation F321, 889 Bilo Road, Zhangjiang Hi-TechPark, Pudong, Shanghai, P.R.China 201203 P.R.China email: zhang.boshan@zte.com.cn Cao, Zhang Expires October 10, 2007 [Page 12] Internet-Draft PPPoE Extensions for multicast/broadcast April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Cao, Zhang Expires October 10, 2007 [Page 13]