Internet DRAFT - draft-caowenli-pppoe-multicast
draft-caowenli-pppoe-multicast
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]
