draft-ietf-ipdvb-ar-06c.txt   draft-ietf-ipdvb-ar-05.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen Internet Draft University of Aberdeen
Document: draft-ietf-ipdvb-ar-06d.txt Marie-Jose Montpetit Document: draft-ietf-ipdvb-ar-05.txt Marie-Jose Montpetit
Motorola Connected Motorola Connected
Home Solutions Home Solutions
IESG DISCUSS - - NOT PUBLISHED
Category: Draft intended as INFO December 2006 Category: Draft intended as INFO August 2006
Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 3, line 21 skipping to change at page 3, line 21
frame, known as a TS Packet, contains a 4 byte header and a 184 byte frame, known as a TS Packet, contains a 4 byte header and a 184 byte
payload. Each TS Packet is associated with a single TS Logical payload. Each TS Packet is associated with a single TS Logical
Channel, identified by a 13-bit Packet ID (PID) value that is Channel, identified by a 13-bit Packet ID (PID) value that is
carried in the MPEG-2 TS Packet header. carried in the MPEG-2 TS Packet header.
The MPEG-2 standard also defines a control plane that may be used to The MPEG-2 standard also defines a control plane that may be used to
transmit control information to Receivers in the form of System transmit control information to Receivers in the form of System
Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific
Information (PSI) Tables. Information (PSI) Tables.
To utilize the MPEG-2 TS as a Layer-2 (L2) link supporting IP, a To utilize the MPEG-2 TS as a Layer-2 (L3) IP link, a sender must
sender must associate an IP address with a particular Transmission associate an IP address with a particular Transmission Multiplex,
Multiplex, and within the multiplex identify the specific PID to be and within the multiplex identify the specific PID to be used. This
used. This document calls this mapping an Address Resolution (AR) document calls this mapping an Address Resolution (AR) function. In
function. In some AR schemes, the MPEG-2 TS address space is sub- some AR schemes, the MPEG-2 TS address space is sub-divided into
divided into logical contexts known as Platforms [ETSI-DAT]. Each logical contexts known as Platforms [ETSI-DAT]. Each Platform
Platform associates an IP service provider with a separate context associates an IP service provider with a separate context that share
that share a common MPEG-2 TS (use the same PID value). a common MPEG-2 TS (use the same PID value).
MPEG-2 Receivers may use a Network Point of Attachment (NPA) MPEG-2 Receivers may use a Network Point of Attachment (NPA)
[RFC4259] to uniquely identify a L2 node within an MPEG-2 [RFC4259] to uniquely identify a L2 node within an MPEG-2
transmission network. An example of an NPA is the IEEE Medium Access transmission network. An example of an NPA is the IEEE Medium Access
Control (MAC) address. Where such addresses are used, these must Control (MAC) address. Where such addresses are used, these must
also be signalled by the AR procedure. Finally, address resolution also be signalled by the AR procedure. Finally, address resolution
could signal the format of the data being transmitted, for example, could signal the format of the data being transmitted, for example,
the encapsulation, any L2 encryption method and any compression the encapsulation, any L2 encryption method and any compression
scheme [RFC4259]. scheme [RFC4259].
skipping to change at page 4, line 53 skipping to change at page 4, line 53
The simplest method uses the L2 address of the transmitted frame. The simplest method uses the L2 address of the transmitted frame.
This is the MAC address corresponding to the destination within the This is the MAC address corresponding to the destination within the
L2 subnetwork (the next hop router, 2b of R2). This requires each L2 subnetwork (the next hop router, 2b of R2). This requires each
Receiver (B4) to associate the receiving MPEG-2 interface with the Receiver (B4) to associate the receiving MPEG-2 interface with the
set of MAC addresses that exist on the L2 subnetworks that it feeds. set of MAC addresses that exist on the L2 subnetworks that it feeds.
Similar considerations apply when IP-based tunnels support L1/L2 Similar considerations apply when IP-based tunnels support L1/L2
services (including the use of UDLR [RFC3077]). services (including the use of UDLR [RFC3077]).
It is also possible for a bridging Encapsulator (B1) to encapsulate It is also possible for a bridging Encapsulator (B1) to encapsulate
a PDU with a link-specific header that also contains the MAC/NPA a PDU with a link-specific header that contains the MAC/NPA address
address associated with a Receiver L2 interface on the MPEG-2 link associated with a Receiver L2 interface on the MPEG-2 link (figure
(figure 2). In this case, the destination MAC/NPA address of the 2). In this case, the destination MAC/NPA address of the
encapsulated frame is set to the Receiver MAC/NPA address (y), encapsulated frame is set to the Receiver MAC/NPA address (y),
rather than the address of the final L2 destination. At a different rather than the address of the final L2 destination. At a different
level, an AR binding is also required for R1 to associate the level, an AR binding is also required for R1 to associate the
destination L2 address 2b with R2. In a subnetwork using bridging, destination L2 address 2b with R2. In a subnetwork using bridging,
the systems R1, R2 will normally use standard IETF-defined AR the systems R1, R2 will normally use standard IETF-defined AR
mechanisms (e.g. IPv4 Address Resolution Protocol, ARP [RFC826] and mechanisms (e.g. IPv4 Address Resolution Protocol, ARP [RFC826] and
the IPv6 Neighbor Discovery Protocol, ND [RFC2461) edge-to-edge the IPv6 Neighbor Discovery Protocol, ND [RFC2461) edge-to-edge
across the IP subnetwork. across the IP subnetwork.
Subnetwork AR Subnetwork AR
skipping to change at page 5, line 42 skipping to change at page 5, line 42
| +----+ | +----+
| |
Figure 2: A bridged MPEG-2 link feeding 3 downstream bridges (B2- Figure 2: A bridged MPEG-2 link feeding 3 downstream bridges (B2-
B4). AR takes place at the Encapsulator (B1) to identify each B4). AR takes place at the Encapsulator (B1) to identify each
Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork
allowing the feed router (R1) to identify the downstream Routers at allowing the feed router (R1) to identify the downstream Routers at
L2 (R2, etc). L2 (R2, etc).
Methods also exist to assign IP addresses to Receivers within a Methods also exist to assign IP addresses to Receivers within a
network (e.g. stateless autoconfiguration [RFC2461], DHCP [RFC2131], network (e.g. DHCP [RFC2131], DHC [RFC3736]). Receivers may also
DHCPv6 [RFC3315], stateless DHCPv6 [RFC3736]). Receivers may also
participate in remote configuration of the L3 IP addresses used in participate in remote configuration of the L3 IP addresses used in
connected equipment (e.g. using DHCP-Relay [RFC3046]). connected equipment (e.g. using DHCP-Relay [RFC3046]).
The remainder of this document describes current mechanisms and The remainder of the document describes current mechanisms and their
their use to associate an IP address with the corresponding TS use to associate an IP address with the corresponding TS Multiplex,
Multiplex, PID value, the MAC/NPA address and/or Platform ID. A PID value, the MAC/NPA address and/or Platform ID. A range of
range of approaches is described, including Layer-2 mechanisms approaches is described, including Layer-2 mechanisms (using MPEG-2
(using MPEG-2 SI tables), and protocols at the IP level (including SI tables), and protocols at the IP level (including ARP [RFC826]
ARP [RFC826] and the ND [RFC2461]). Interactions and dependencies and the ND [RFC2461]). Interactions and dependencies between these
between these mechanisms and the encapsulation methods are mechanisms and the encapsulation methods are described. The document
described. The document does not propose or define a new protocol, does not propose or define a new protocol, but does provide guidance
but does provide guidance on issues that would need to be considered on issues that would need to be considered to supply IP-based
to supply IP-based address resolution. address resolution.
2. Conventions used in this document 2. Conventions used in this document
AIT: Application Information Table specified by the Multimedia Home AIT: Application Information Table specified by the Multimedia Home
Platform (MHP) specifications [ETSI-MHP]. This table may carry Platform (MHP) specifications [ETSI-MHP]. This table may carry
IPv4/IPv6 to MPEG-2 TS address resolution information. IPv4/IPv6 to MPEG-2 TS address resolution information.
ATSC: Advanced Television Systems Committee [ATSC]. A framework and ATSC: Advanced Television Systems Committee [ATSC]. A framework and
a set of associated standards for the transmission of video, audio, a set of associated standards for the transmission of video, audio,
and data using the ISO MPEG-2 standard [ISO-MPEG2]. and data using the ISO MPEG-2 standard [ISO-MPEG2].
skipping to change at page 10, line 25 skipping to change at page 10, line 25
A scalable architecture that may support large numbers of A scalable architecture that may support large numbers of
systems within the MPEG-2 network [RFC4259]. systems within the MPEG-2 network [RFC4259].
A protocol version, to indicate the specific AR protocol in use A protocol version, to indicate the specific AR protocol in use
and which may include the supported encapsulation method. and which may include the supported encapsulation method.
A method (e.g. well-known L2/L3 address/addresses) to identify A method (e.g. well-known L2/L3 address/addresses) to identify
the AR Server sourcing the AR information. the AR Server sourcing the AR information.
A method to represent IPv4/IPv6 AR information (including A method to represent IPv4/IPv6 AR information (including
security mechanisms to authenticate the AR information that security associations to authenticate the AR information that
will prevent address masquerading [RFC3756]). will prevent address masquerading [RFC3756]).
A method to install AR information associated with clients at A method to install AR information associated with clients at
the AR Server (registration). the AR Server (registration).
A method for transmission of AR information from an AR Server A method for transmission of AR information from an AR Server
to clients that minimise the transmission cost (link local to clients that minimise the transmission cost (link local
multicast, is preferable to subnet broadcast). multicast, is preferable to subnet broadcast).
Incremental update of the AR information held by clients. Incremental update of the AR information held by clients.
skipping to change at page 12, line 20 skipping to change at page 12, line 20
Multicast is an important application for MPEG-2 Transmission Multicast is an important application for MPEG-2 Transmission
Networks, since it exploits the advantages of native support for Networks, since it exploits the advantages of native support for
link broadcast. Multicast address resolution occurs at the network- link broadcast. Multicast address resolution occurs at the network-
level in associating a specific L2 address with an IP Group level in associating a specific L2 address with an IP Group
Destination Address (section 5.6). In IPv4 and IPv6 over Ethernet, Destination Address (section 5.6). In IPv4 and IPv6 over Ethernet,
this association is normally a direct mapping, and this is the this association is normally a direct mapping, and this is the
default method also specified in both ULE [RFC4326] and MPE [ETSI- default method also specified in both ULE [RFC4326] and MPE [ETSI-
DAT]. DAT].
Address resolution must also occur at the MPEG-2 level (section 4). Address resolution must also occur at the MPEG-2 level (section 4).
The goal of this multicast address resolution is to allow a receiver The goal of this multicast address resolution is the association of
to associate an IPv4 or IPv6 multicast address with a specific TS an IPv4 or IPv6 multicast address with a specific TS Logical Channel
Logical Channel and the corresponding TS Multiplex [RFC4259]. This and the corresponding TS Multiplex. This association needs to
association needs to permit a large number of active multicast permit a large number of active multicast groups, and should
groups, and should minimise the processing load at the Receiver when minimise the processing load at the Receiver when filtering and
filtering and forwarding IP multicast packets (e.g. by distributing forwarding IP multicast packets (e.g. by distributing the multicast
the multicast traffic over a number of TS Logical Channels). Schemes traffic over a number of TS Logical Channels). Schemes that allow
that allow hardware filtering can be beneficial, since these may hardware filtering can be beneficial, since these may relieve the
relieve the drivers and operating systems from discarding unwanted drivers and operating systems from discarding unwanted multicast
multicast traffic. traffic.
There are two specific functions required for address resolution in There are two specific functions required for address resolution in
IP multicast over MPEG-2 Networks: IP multicast over MPEG-2 Networks:
(i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical (i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical
Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator. Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator.
(ii) Provide signalling information to allow a Receiver to (ii) Provide signalling information to allow a Receiver to
locate an IP multicast flow within an MPEG-2 TS Multiplex. locate an IP multicast flow within an MPEG-2 TS Multiplex.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
When the MPEG-2 Network is peered to the multicast-enabled Internet, When the MPEG-2 Network is peered to the multicast-enabled Internet,
an arbitrarily large number of IP multicast group destination an arbitrarily large number of IP multicast group destination
addresses may be in use, and the set forwarded on the transmission addresses may be in use, and the set forwarded on the transmission
network may be expected to vary significantly with time. Some uses network may be expected to vary significantly with time. Some uses
of IP multicast employ a range of addresses to support a single of IP multicast employ a range of addresses to support a single
application (e.g., ND [RFC2461], LCT [RFC3451], WEBRC [RFC3738]). application (e.g., ND [RFC2461], LCT [RFC3451], WEBRC [RFC3738]).
The current set of active addresses may be determined dynamically The current set of active addresses may be determined dynamically
via a multicast group membership protocol (e.g., IGMP [RFC3376], MLD via a multicast group membership protocol (e.g., IGMP [RFC3376], MLD
[RFC3810]), via multicast routing (e.g., PIM [RFC2362]) and/or other [RFC3810]), via multicast routing (e.g., PIM [RFC2362]) and/or other
means (e.g. [RFC3819], [RFC4605]), however each active address means (e.g. [RFC3819], [RFC-IGMP-Proxy]), however each active
requires a binding by the AR method. There are therefore advantages address requires a binding by the AR method. There are therefore
in using a method that does not need to explicitly advertise an AR advantages in using a method that does not need to explicitly
binding for each IP traffic flow, but is able to distribute traffic advertise an AR binding for each IP traffic flow, but is able to
across a number of L2 TS Logical Channels (e.g., using a distribute traffic across a number of L2 TS Logical Channels (e.g.,
hash/mapping that resembles the mapping from IP addresses to MAC using a hash/mapping that resembles the mapping from IP addresses to
addresses [RFC1112, RFC2464]). Such methods can reduce the volume of MAC addresses [RFC1112, RFC2464]). Such methods can reduce the
AR information that needs to be distributed, and reduce the AR volume of AR information that needs to be distributed, and reduce
processing. the AR processing.
Section 5.6 describes the binding of IP multicast addresses to Section 5.6 describes the binding of IP multicast addresses to
MAC/NPA addresses. MAC/NPA addresses.
4. MPEG-2 Address Resolution 4. MPEG-2 Address Resolution
The first part of this section describes the role of MPEG-2 The first part of this section describes the role of MPEG-2
signalling to identify streams (TS Logical Channels [RFC4259]) signalling to identify streams (TS Logical Channels [RFC4259])
within the L2 infrastructure. within the L2 infrastructure.
skipping to change at page 21, line 50 skipping to change at page 21, line 50
Secure ARP (SARP) uses a secure tunnel (e.g. between each client and Secure ARP (SARP) uses a secure tunnel (e.g. between each client and
a server at a wireless access point or router) [RFC2246]. The router a server at a wireless access point or router) [RFC2246]. The router
ignores any ARP responses not associated with clients using the ignores any ARP responses not associated with clients using the
secure tunnels. Therefore, only legitimate ARP Responses are used secure tunnels. Therefore, only legitimate ARP Responses are used
for updating ARP tables. SARP requires the installation of software for updating ARP tables. SARP requires the installation of software
at each client. It suffers from the same scalability issues as the at each client. It suffers from the same scalability issues as the
standard ARP. standard ARP.
The ND protocol uses a set of IP multicast addresses. In large The ND protocol uses a set of IP multicast addresses. In large
networks, many multicast addresses are used, but each client networks, many multicast addresses are used, but clients typically
typically only listens to a restricted set of group destination only listen to a restricted set of group destination addresses and
addresses and little traffic is usually sent in each group. Layer-2 little traffic is usually sent in each group. Layer-2 AR for MPEG-2
AR for MPEG-2 Networks therefore must support this in a scalable Networks therefore must support this in a scalable manner.
manner.
A large number of ND messages may cause a large demand for A large number of ND Router Solicitation messages may cause a large
performing asymmetric operations. The base ND protocol limits the demand for performing asymmetric operations. The base ND protocol
rate at which multicast responses to solicitations can be sent, limits the rate at which multicast responses to solicitations can be
configurations may need to be tuned when operating with large sent, configurations may need to be tuned when operating with large
numbers of Receivers. numbers of Receivers.
The default parameters specified in RFC 2461 for the ND protocol can The default parameters specified in RFC 2461 for the ND protocol can
introduce interoperability problems (e.g. a failure to resolve when introduce interoperability problems (e.g. a failure to resolve when
the link RTT exceed 3 seconds) and performance degradation the link RTT exceed 3 seconds) and performance degradation
(duplicate ND messages with a link RTT > 1 second) when used in (duplicate ND messages with a link RTT > 1 second) when used in
networks were the link RTT is significantly larger than experienced networks were the link RTT is significantly larger than experienced
by Ethernet LANs. Tuning of the protocol parameters (e.g. by Ethernet LANs. Tuning of the protocol parameters (e.g.
RTR_SOLICITATION_INTERVAL) is therefore recommended when using RTR_SOLICITATION_INTERVAL) is therefore recommended when using
network links with appreciable delay (Section 6.3.2 of [RFC2461]). network links with appreciable delay (Section 6.3.2 of [RFC2461]).
ND has similar security vulnerabilities to ARP. The Secure Neighbor ND has similar security vulnerabilities to ARP. The Secure Neighbor
Discovery, SEND [RFC3971] was developed to address known security Discovery, SEND [RFC3971] was developed to address known security
vulnerabilities in ND [RFC3756]. It can also reduce the AR traffic vulnerabilities in ND [RFC3756]. It can also reduce the AR traffic
compared to ND. In addition, SEND does not require the configuration compared to ND. SEND also does not impact the IPsec architecture and
of per-host keys and can co-exist with the use of both SEND and implementations, and provides improved support for security
insecure ND on the same link. decisions based on application state. This allows co-existence of
SEND and insecure ND on the same link.
The ND Protocol is also used to perform other functions beyond
address resolution, including Router Solicitation / Advertisement,
Duplicate Address Detection (DAD), Neighbor Unreachability Detection
(NUD), Redirect. These functions are useful for hosts, even when
address resolution is not required.
5.1 Uni-directional links supporting uni-directional connectivity 5.1 Uni-directional links supporting uni-directional connectivity
MPEG-2 Networks may provide a Uni-Directional broadcast Link (UDL), MPEG-2 Networks may provide a Uni-Directional broadcast Link (UDL),
with no return path. Such links may be used for unicast applications with no return path. Such links may be used for unicast applications
that do not require a return path (e.g. based on UDP), but commonly that do not require a return path (e.g. based on UDP), but commonly
are used for IP multicast content distribution. are used for IP multicast content distribution.
/-----\ /-----\
MPEG-2 Uplink /MPEG-2 \ MPEG-2 Uplink /MPEG-2 \
skipping to change at page 26, line 23 skipping to change at page 26, line 14
Current IETF-defined methods provide bindings of IP addresses to Current IETF-defined methods provide bindings of IP addresses to
MAC/NPA, but do not allow the bindings to other L2 information MAC/NPA, but do not allow the bindings to other L2 information
pertinent to MPEG-2 Networks, requiring the use of other methods for pertinent to MPEG-2 Networks, requiring the use of other methods for
this function (section 4). AR Servers can also be implemented using this function (section 4). AR Servers can also be implemented using
non-IETF AR protocols to provide the AR information required by non-IETF AR protocols to provide the AR information required by
Receivers. Receivers.
5.5 DHCP Tuning 5.5 DHCP Tuning
DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 DHCP [RFC2131] may be used over MPEG-2 Networks. DHCP consists of
Networks. DHCP consists of two components: a protocol for delivering two components: a protocol for delivering system-specific
system-specific configuration parameters from a DHCP server to a configuration parameters from a DHCP server to a DHCP client (e.g.
DHCP client (e.g. default router, DNS server) and a mechanism for default router, DNS server) and a mechanism for allocation of
allocation of network addresses to systems. network addresses to systems. DHCP messages (e.g. DHCPDISCOVER,
DHCPREQUEST, DHCPOFFER) may include options [RFC2131].
The configuration of DHCP Servers and Clients should take into The configuration of DHCP Servers and Clients should take into
account the local link round trip delay (possibly including the account the local link round trip delay (possibly including the
additional delay from bridging, e.g. using UDLR). A large number of additional delay from bridging, e.g. using UDLR). A larger delay
clients can make it desirable to tune the DHCP lease duration and makes it desirable to tune the DHCP lease duration and the size of
the size of the address pool. Appropriate timer values should also the address pool. Appropriate timer values should also be selected:
be selected: the DHCP messages retransmission timeout, and the the DHCP messages retransmission timeout, and the maximum delay that
maximum delay that a DHCP Server waits before deciding that the a DHCP Server waits before deciding that the absence of an ICMP echo
absence of an ICMP echo response indicates that the relevant address response indicates that the relevant address is free.
is free.
DHCP Clients may retransmit DHCP messages if they do not receive a DHCP Clients may retransmit DHCP messages if they do not receive a
response. Some client implementations specify a timeout for the response. Some client implementations specify a timeout for the
DHCPDISCOVER message that is small (e.g. suited to Ethernet delay, DHCPDISCOVER message that is small (e.g. suited to Ethernet delay,
rather than appropriate to a MPEG-2 Network) providing insufficient rather than appropriate to a MPEG-2 Network) providing insufficient
time for a DHCP Server to respond to a DHCPDISCOVER retransmission time for a DHCP Server to respond to a DHCPDISCOVER retransmission
before expiry of the check on the lease availability (by an ICMP before expiry of the check on the lease availability (by an ICMP
echo request), resulting in potential address conflict. This value echo request), resulting in potential address conflict. This value
may need to be tuned for MPEG-2 networks. may need to be tuned for MPEG-2 networks.
skipping to change at page 27, line 52 skipping to change at page 27, line 42
multicast forwarding does not include the normal L3 Reverse Path multicast forwarding does not include the normal L3 Reverse Path
Forwarding (RPF) check or L2 spanning tree checks, the processing of Forwarding (RPF) check or L2 spanning tree checks, the processing of
the IP Time To Live (TTL) field, or the filtering of the IP Time To Live (TTL) field, or the filtering of
administratively scoped multicast addresses. This raises a need to administratively scoped multicast addresses. This raises a need to
carefully consider multicast support. To avoid forwarding loops, carefully consider multicast support. To avoid forwarding loops,
RFC3077 notes that a Receiver needs to be configured with RFC3077 notes that a Receiver needs to be configured with
appropriate filter rules to ensure it discards packets that appropriate filter rules to ensure it discards packets that
originate from an attached network and are later received over the originate from an attached network and are later received over the
feed link. feed link.
When the encapsulation includes an MAC/NPA source address, re- When the encapsulation includes an MAC/NPA source address, such
broadcast packets may be filtered at the link-layer using a filter packets may be filtered at the link-layer using a filter that
that discards L2 addresses that are local to the Receiver. In some discards L2 addresses that are local to the Receiver. In some
circumstances, systems can send packets with an unknown (all zero) circumstances, systems can send packets with an unknown (all zero)
MAC source address (e.g. IGMP Proxy Queriers [RFC4605]), where the MAC source address (e.g. IGMP Proxy Queriers [RFC-IGMP-Proxy]),
source at L2 can not be determined at the Receiver, these packets where the source at L2 can not be determined at the Receiver, these
need to be silently discarded, which may prevent running the packets need to be silently discarded, which may prevent running the
associated services on the Receiver. associated services on the Receiver.
Some encapsulations also do not include an MAC/NPA source address Some encapsulations do not include an MAC/NPA source address (Table
(Table 2). Multicast packets may therefore alternatively be 2). Multicast packets may therefore alternatively be discarded at
discarded at the IP layer if their IP source address matches a local the IP layer if their IP source address matches a local IP address
IP address (or address range). Systems can send packets with an all (or address range). Systems can send packets with an all zero IP
zero IP source address (e.g. BOOTP [RFC951], DHCP [RFC2131] and ND source address (e.g. BOOTP [RFC951], DHCP [RFC2131] and ND
[RFC2461]), where the source at L3 can not be determined at the [RFC2461]), where the source at L3 can not be determined at the
Receiver these packets need to be silently discarded. This may Receiver these packets need to be silently discarded. This may
prevent running the associated services at a Receiver, e.g. prevent running the associated services at a Receiver, e.g.
participation in IPv6 Duplicate Address Detection, or running a DHCP participation in IPv6 Duplicate Address Detection, or running a DHCP
server. server.
6. Link Layer Support 6. Link Layer Support
This section considers link-layer (L2) support for address This section considers link-layer (L2) support for address
resolution in MPEG-2 Networks. It considers two issues: The code- resolution in MPEG-2 Networks. It considers two issues: The code-
point used at L2 and the efficiency of encapsulation for point used at L2 and the efficiency of encapsulation for
transmission required to support the AR method. The table below transmission required to support the AR method. The table below
summarises the options for both MPE [ETSI-DAT] and ULE [RFC4326] summarises the options for both MPE [ETSI-DAT] and ULE [RFC4326]
encapsulations. encapsulations.
[ID-IAB-LINK] describes issues and concerns that can arise when a
link can support multiple encapsulations. In particular, it
identifies problems that arise when end hosts that belong to the
same IP network employ different incompatible encapsulation methods.
An Encapsulator must therefore use only one method ULE or MPE) to
support a single IP network (i.e. set of IPv4 systems sharing the
same subnet broadcast address, or same IPv6 Prefix). In this way,
all Receivers belonging to a network will Receive the same set of
multicast/broadcast messages.
ULE bridging may be used in combination with the normal mode too
address packets to a receiver (all ULE Receivers are required to
implement both methods). Frames carrying IP packets using the ULE
Bridging mode that have a destination address corresponding to the
MAC address of the Receiver and have an IP address corresponding to
a Receiver interface will be delivered to the IP stack of the
Receiver. All bridged IP multicast and broadcast frames will also be
copied to the IP stack of the Receiver. Receivers must filter
(discard) a frame that carries a MAC source address of a system that
is reachable via a different network interface to that upon which it
is received, including reception of a frame with an address that
matches the source address of the Receiver itself [802.1D].
+-------------------------------+--------+----------------------+ +-------------------------------+--------+----------------------+
| | PDU |L2 Frame Header Fields| | | PDU |L2 Frame Header Fields|
| L2 Encapsulation |overhead+----------------------+ | L2 Encapsulation |overhead+----------------------+
| |[bytes] |src mac|dst mac| type | | |[bytes] |src mac|dst mac| type |
+-------------------------------+--------+-------+-------+------+ +-------------------------------+--------+-------+-------+------+
|6.1 ULE without dst MAC address| 8 | - | - | x | |6.1 ULE without dst MAC address| 8 | - | - | x |
|6.2 ULE with dst MAC address | 14 | - | x | x | |6.2 ULE with dst MAC address | 14 | - | x | x |
|6.3 MPE without LLC/SNAP | 16 | - | x | - | |6.3 MPE without LLC/SNAP | 16 | - | x | - |
|6.4 MPE with LLC/SNAP | 24 | - | x | x | |6.4 MPE with LLC/SNAP | 24 | - | x | x |
|6.5 ULE with Bridging extension| 22 | x | x | x | |6.5 ULE with Bridging extension| 22 | x | x | x |
|6.6 ULE with Bridging & NPA | 28 | x | x | x | |6.6 ULE with Bridging & NPA | 28 | x | x | x |
|6.7 MPE+LLC/SNAP+Bridging | 38 | x | x | x | |6.7 MPE+LLC/SNAP+Bridging | 38 | x | x | x |
+-------------------------------+--------+-------+-------+------+ +-------------------------------+--------+-------+-------+------+
Table showing L2 support and overhead (x=supported, -=not supported) Table showing L2 support and overhead (x=supported, -=not supported)
The remainder of the section describes IETF-specified AR methods for The remainder of the section describes IETF-specified AR methods for
use with these encapsulation formats. Most of these methods rely on use with these encapsulation formats.
bi-directional communications (see section 5.1, 5.2, 5.3 for a
discussion of this).
6.1 ULE without a destination MAC/NPA address (D=1) 6.1 ULE without a destination MAC/NPA address (D=1)
The ULE encapsulation supports a mode (D=1) where the MAC/NPA The ULE encapsulation supports a mode (D=1) where the MAC/NPA
address is not present in the encapsulated frame. This mode may be address is not present in the encapsulated frame. This mode may be
used with both IPv4 and IPv6. When used, the Receiver is expected used with both IPv4 and IPv6. When used, the Receiver is expected
to perform L3 filtering of packets based on their IP destination to perform L3 filtering of packets based on their IP destination
address [RFC4326]. This requires careful consideration of the address [RFC4326]. This requires careful consideration of the
network topology when a receiver is an IP router, or delivers data network topology when a receiver is an IP router, or delivers data
to an IP router (a simple case where this is permitted arises in the to an IP router (a simple case where this is permitted arises in the
connection of stub networks that have no connectivity to other connection of stub networks that have no connectivity to other
networks). Since there is no MAC/NPA address in the SNDU, ARP and networks). Since there is no MAC/NPA address in the SNDU, ARP and
the ND protocol are not required for AR. NDP are not required.
IPv6 systems can automatically configure their IPv6 network address IPv6 systems can automatically configure their IPv6 network address
based upon a local MAC address [RFC2462]. To use auto-configuration, based upon a local MAC address [RFC2462]. To use auto-configuration,
the IP driver at the Receiver may need to access the MAC/NPA address the IP driver at the Receiver may need to access the MAC/NPA address
of the receiving interface, even though this value is not being used of the receiving interface, even though this value is not being used
to filter received SNDUs. to filter received SNDUs.
The ND protocol may still be required to support DAD, and other
network-layer functions. The protocol uses a block of IPv6 multicast
addresses, which need to be carried by the L2 network. However,
since this encapsulation format does not provide a MAC source
address, there are topologies (e,g. section 5.6.1) where a system
can not differentiate DAD packets that were originally sent by
itself and were re-broadcast, from those that may have been sent by
another system with the same L3 address. DAD therefore can not be
used with this encapsulation format in topologies where this L2
forwarding may occur.
6.2 ULE with a destination MAC/NPA address (D=0) 6.2 ULE with a destination MAC/NPA address (D=0)
The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by
an IEEE EtherType and may be used over ULE [RFC4326]. Although no an IEEE EtherType and may be used over ULE [RFC4326]. Although no
MAC source address is present in the ULE SNDU, the ARP protocol MAC source address is present in the ULE SNDU, the ARP protocol
still communicates the source MAC (hardware) address in the ARP still communicates the source MAC (hardware) address in the ARP
record payload of any query messages that it generates. record payload of any query messages that it generates.
The IPv6 ND protocol is supported. The protocol uses a block of IPv6 The IPv6 ND protocol is supported. The protocol uses a block of IPv6
multicast addresses, which need to be carried by the L2 network. The multicast addresses, which need to be carried by the L2 network. The
protocol uses a block of IPv6 multicast addresses, which need to be protocol does not require specification of a MAC source address,
carried by the L2 network. However, since this encapsulation format although this is required for a node to participate in Duplicate
does not provide a MAC source address, there are topologies (e,g. Address Detection (DAD) [RFC2462].
section 5.6.1) where a system can not differentiate DAD packets that
were originally sent by itself and were re-broadcast, from those
that may have been sent by another system with the same L3 address.
DAD therefore can not be used with this encapsulation format in
topologies where this L2 forwarding may occur.
6.3 MPE without LLC/SNAP Encapsulation 6.3 MPE without LLC/SNAP Encapsulation
This is the default (and sometimes only) mode specified by most MPE This is the default (and sometimes only) mode specified by most MPE
Encapsulators. MPE does not provide an EtherType field and therefore Encapsulators. MPE does not provide an EtherType field and therefore
can not support the Address Resolution Protocol (ARP) [RFC826]. can not support the Address Resolution Protocol (ARP) [RFC826].
IPv6 is not supported in this encapsulation format, and therefore it IPv6 is not supported in this encapsulation format, and therefore it
is not appropriate to consider the ND protocol. is not appropriate to consider the ND protocol.
6.4 MPE with LLC/SNAP Encapsulation 6.4 MPE with LLC/SNAP Encapsulation
The LLC/SNAP format of MPE provides an EtherType field and therefore The LLC/SNAP format of MPE provides an EtherType field and therefore
may support the ARP [RFC826]. There is no specification to define may support the ARP [RFC826]. There is no specification to define
how this is performed. No MAC source address is present in the SNDU, how this is performed. No MAC source address is present in the SNDU,
although the protocol still communicates the source MAC address in although the protocol still communicates the source MAC address in
the ARP record payload of any query messages that it generates. the ARP record payload of any query messages that it generates.
The IPv6 ND protocol is supported using The LLC/SNAP format of MPE. The IPv6 ND protocol is supported using The LLC/SNAP format of MPE.
This requires specific multicast addresses to be carried by the L2 This requires specific multicast addresses to be carried by the L2
network. The IPv6 ND protocol is supported. The protocol uses a network. The MAC source address permits the node to participate in
block of IPv6 multicast addresses, which need to be carried by the DAD [RFC2462].
L2 network. However, since this encapsulation format does not
provide a MAC source address, there are topologies (e,g. section
5.6.1) where a system can not differentiate DAD packets that were
originally sent by itself and were re-broadcast, from those that may
have been sent by another system with the same L3 address, DAD
therefore can not be used with this encapsulation format in
topologies where this L2 forwarding may occur.
6.5 ULE with Bridging Header Extension (D=1) 6.5 ULE with Bridging Header Extension (D=1)
The ULE encapsulation supports a bridging extension header that The ULE encapsulation supports a bridging extension header that
supplies both a source and destination MAC address. This can be supplies both a source and destination MAC address. This can be
used without an NPA address (D=1). When no other Extension Headers used without an NPA address (D=1). When no other Extension Headers
are present, the MAC destination address has the same position in are present, the MAC destination address has the same position in
the ULE SNDU as that used for an NPA destination address. The the ULE SNDU as that used for an NPA destination address. The
Receiver may optionally be configured so that the MAC destination Receiver may optionally be configured so that the MAC destination
address value is identical to a Receiver NPA address. address value is identical to a Receiver NPA address.
At the Encapsulator, the ULE MAC/NPA destination address is At the Encapsulator, the ULE MAC/NPA destination address is
determined by a L2 forwarding decision. Received frames may be determined by a L2 forwarding decision. Received frames may be
forwarded or may be addressed to the Receiver itself. As in other L2 forwarded or may be addressed to the Receiver itself. As in other L2
LANs, the Receiver may choose to filter received frames based on a LANs, the Receiver may choose to filter received frames based on a
configured MAC destination address filter. ARP and ND messages may configured MAC destination address filter. ARP and ND messages may
be carried within a PDU that is bridged by this encapsulation be carried within a PDU that is bridged by this encapsulation
format. Where the topology may result in subsequent reception of re- format.
broadcast copies of multicast frames that were originally sent by a
Receiver (e,g. section 5.6.1), the system must discard frames that
are received with a source address that it used in frames sent from
the same interface [802.1D]. This prevents duplication on the
bridged network (e.g. this would otherwise invoke DAD).
6.6 ULE with Bridging Header Extension and NPA Address (D=0) 6.6 ULE with Bridging Header Extension and NPA Address (D=0)
The combination of a NPA address (D=0) and a bridging extension The combination of a NPA address (D=0) and a bridging extension
header are allowed in ULE. This SNDU format supplies both a source header are allowed in ULE. This SNDU format supplies both a source
and destination MAC address and a NPA destination address (i.e. and destination MAC address and a NPA destination address (i.e.
Receiver MAC/NPA address). Receiver MAC/NPA address).
At the Encapsulator, the value of the ULE MAC/NPA destination At the Encapsulator, the value of the ULE MAC/NPA destination
address is determined by a L2 forwarding decision. At the Receiver, address is determined by a L2 forwarding decision. At the Receiver,
frames may be forwarded or may be addressed to the Receiver itself. frames may be forwarded or may be addressed to the Receiver itself.
As in other L2 LANs, the Receiver may choose to filter received As in other L2 LANs, the Receiver may choose to filter received
frames based on a configured MAC destination address filter. ARP and frames based on a configured MAC destination address filter. ARP and
ND messages may be carried within a PDU that is bridged by this ND messages may be carried within a PDU that is bridged by this
encapsulation format. Where the topology may result in subsequent encapsulation format.
reception of re-broadcast copies of multicast frames that were
originally sent by a Receiver (e,g. section 5.6.1), the system must
discard frames that are received with a source address that it used
in frames sent from the same interface [802.1D]. This prevents
duplication on the bridged network (e.g. this would otherwise invoke
DAD).
6.7 MPE+LLC/SNAP+Bridging 6.7 MPE+LLC/SNAP+Bridging
The LLC/SNAP format MPE frames may optionally support an IEEE The LLC/SNAP format MPE frames may optionally support an IEEE
bridging header [LLC]. This header supplies both a source and bridging header [LLC]. This header supplies both a source and
destination MAC address, at the expense of larger encapsulation destination MAC address, at the expense of larger encapsulation
overhead. The format defines two MAC destination addresses, one overhead. The format defines two MAC destination addresses, one
associated with the MPE SNDU (i.e. Receiver MAC address) and one associated with the MPE SNDU (i.e. Receiver MAC address) and one
with the bridged MAC frame (i.e. the MAC address of the intended with the bridged MAC frame (i.e. the MAC address of the intended
recipient in the remote LAN). recipient in the remote LAN).
At the Encapsulator, the MPE MAC destination address is determined At the Encapsulator, the MPE MAC destination address is determined
by a L2 forwarding decision. There is currently no formal by a L2 forwarding decision. A Receiver may forward frames or they
description of the Receiving processing for this encapsulation may be addressed to the Receiver itself. As in other L2 LANs, the
format. A Receiver may forward frames or they may be addressed to Receiver may choose to filter received frames based on a configured
the Receiver itself. As in other L2 LANs, the Receiver may choose to MAC destination address filter. ARP and ND messages may be carried
filter received frames based on a configured MAC destination address within a PDU that is bridged by this encapsulation format. The MPE
filter. ARP and ND messages may be carried within a PDU that is MAC destination address is determined by a L2 forwarding decision.
bridged by this encapsulation format. The MPE MAC destination
address is determined by a L2 forwarding decision. Where the
topology may result in subsequent reception of re-broadcast copies
of multicast frames that were originally sent by a Receiver (e,g.
section 5.6.1), the system must discard frames that are received
with a source address that it used in frames sent from the same
interface [802.1D]. This prevents duplication on the bridged network
(e.g. this would otherwise invoke DAD).
7. Conclusions 7. Conclusions
This document describes addressing and address resolution issues for This document describes addressing and address resolution issues for
IP protocols over MPEG-2 transmission networks using both wired and IP protocols over MPEG-2 transmission networks using both wired and
wireless technologies. A number of specific IETF protocols are wireless technologies. A number of specific IETF protocols are
discussed along with their expected behaviour over MPEG-2 discussed along with their expected behaviour over MPEG-2
transmission networks. Recommendations for their usage are provided. transmission networks. Recommendations for their usage are provided.
There is no single common approach used in all MPEG-2 networks. A There is no single common approach used in all MPEG-2 networks. A
skipping to change at page 35, line 48 skipping to change at page 34, line 48
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links",
RFC 3077, March 2001. RFC 3077, March 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional [RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP datagrams Lightweight Encapsulation (ULE) for transmission of IP datagrams
over an MPEG-2 Transport Stream", RFC 4326, December 2005. over an MPEG-2 Transport Stream", RFC 4326, December 2005.
10.2 Informative References 10.2 Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced [ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004. Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television
skipping to change at page 36, line 50 skipping to change at page 35, line 45
[ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai,
"Security requirements for the Unidirectional Lightweight "Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", Work in Progress, draft-cruickshank- Encapsulation (ULE) protocol", Work in Progress, draft-cruickshank-
ipdvb-sec-req-xx.txt. ipdvb-sec-req-xx.txt.
[ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C., "ISP IPv6 [ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C., "ISP IPv6
Deployment Scenarios in Broadband Access Networks" Deployment Scenarios in Broadband Access Networks"
draft-ietf-v6ops-bb-deployment-scenarios-04.txt, Work in Progress, draft-ietf-v6ops-bb-deployment-scenarios-04.txt, Work in Progress,
v6ops WG. XXX Publication Requested XX v6ops WG. XXX Publication Requested XX
[ID-IAB-LINK] Aboba, B., Davies, E., Thaler, D., "Multiple
Encapsulation Methods Considered Harmful"", Work in Progress, draft-
iab-link-encaps-00.txt.
[ID-SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem [ID-SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem
Statement", Work in progress, draft-daley-send-spnd-prob-01.txt, Statement", Work in progress, draft-daley-send-spnd-prob-01.txt,
February 2005. February 2005.
[802.1D] "IEEE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges", IEEE, 204.
[LLC] ISO/IEC 8802.2, "Information technology; Telecommunications [LLC] ISO/IEC 8802.2, "Information technology; Telecommunications
and information exchange between systems; Local and metropolitan and information exchange between systems; Local and metropolitan
area networks; Specific requirements; Part 2: Logical Link Control", area networks; Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998. International Standards Organisation (ISO), 1998.
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
skipping to change at page 38, line 8 skipping to change at page 36, line 45
Sooriyabandara, "TCP Performance Implications of Network Path Sooriyabandara, "TCP Performance Implications of Network Path
Asymmetry", BCP 69, RFC 3449, December 2002. Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley,
M., and J. Crowcroft, "Layered Coding Transport (LCT) Building M., and J. Crowcroft, "Layered Coding Transport (LCT) Building
Block", RFC 3451, December 2002. Block", RFC 3451, December 2002.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003. Multicast (SSM)", RFC 3569, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004. Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
skipping to change at page 38, line 32 skipping to change at page 37, line 20
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4259] Montpetit, M.J., Fairhurst, G., Clausen, H.D., Collini- [RFC4259] Montpetit, M.J., Fairhurst, G., Clausen, H.D., Collini-
Nocker, B., and H. Linder, "Architecture for IP transport Nocker, B., and H. Linder, "Architecture for IP transport
over MPEG-2 Networks". over MPEG-2 Networks".
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4605] B Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC-IGMP-Proxy] B. Fenner,H. He, B. Haberman, H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast Listener l"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")", RFC
Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", XXX, 2006. <currently draft-ietf-magma-igmp-proxy-06.txt>
RFC 4605, August 2006.
[SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6, [SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6,
March 2002. March 2002.
11. Authors' Addresses 11. Authors' Addresses
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
University of Aberdeen University of Aberdeen
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
skipping to change at page 42, line 40 skipping to change at page 40, line 39
distributed to systems in a different L3 network or distributed to systems in a different L3 network or
multicast scope (see sections 3.2 and 5.6)" multicast scope (see sections 3.2 and 5.6)"
* Section 2, Added: * Section 2, Added:
MAC Address: A 6 byte link layer address of the format described by MAC Address: A 6 byte link layer address of the format described by
the Ethernet IEEE 802 standard (see also NPA). the Ethernet IEEE 802 standard (see also NPA).
* Section 3, Revised bullet into two points: * Section 3, Revised bullet into two points:
A scalable architecture that may support large numbers of systems A scalable architecture that may support large numbers of systems
within the MPEG-2 network [RFC4259]. within the MPEG-2 network [RFC4259].
A method for transmission of AR information from an AR Server to A method for transmission of AR information from an AR Server to
clients that minimise the transmission cost (link local multicast, clients that minimise the transmission cost (link local multicast,
is preferable to subnet broadcast). is preferable to subnet broadcast).
* Section 3, changed *context* to *scope* * Section 3, changed context to scope
* Section 4.3. Revised wording on T Stream v. TS Logical Channel. * Section 4.3. Revised wording on T Stream v. TS Logical Channel.
* Section 5.4. 2nd para, added *(mapping the IP address to the L2 * Section 5.4. 2nd para, added (mapping the IP address to the L2
address)* address)
* Added: * Added:
The default parameters specified in RFC 2461 for the ND protocol can The default parameters specified in RFC 2461 for the ND protocol can
introduce interoperability problems (e.g. a failure to resolve when introduce interoperability problems (e.g. a failure to resolve when
the link RTT exceed 3 seconds) and performance degradation the link RTT exceed 3 seconds) and performance degradation
(duplicate ND messages with a link RTT > 1 second) when used in (duplicate ND messages with a link RTT > 1 second) when used in
networks were the link RTT is significantly larger than experienced networks were the link RTT is significantly larger than experienced
by Ethernet LANs. Tuning of the protocol parameters (e.g. by Ethernet LANs. Tuning of the protocol parameters (e.g.
RTR_SOLICITATION_INTERVAL) is therefore recommended when using RTR_SOLICITATION_INTERVAL) is therefore recommended when using
Network links with appreciable delay (Section 6.3.2 of [RFC2461]). network links with appreciable delay (Section 6.3.2 of [RFC2461]).
WG-06 (following IESG Discuss)
1)
>
> Considerations from draft-iab-link-encaps-05 apply.
> The use of different address resolution mechanisms
> adds new issues. The draft should make it clear
> what the interoperability implications of this
> situation are, and, hopefully, talk about how
> the involved nodes can determine what to do.
>
Yes, I spoke to Bernhard about his I-D at the IETF meeting, in a
different context - so I understand some of the issues (but not from
an AR viewpoint), I'll look at this - I really need to read/think
to, I think that would be valuable.
- We will take this as an action.
-------------------------------------------------------
2)
Methods also exist to assign IP addresses to Receivers within a
network (e.g. DHCP [RFC2131], DHC [RFC3736]).
- Replaced by stateless autoconfiguration [RFC2461], DHCP [RFC2131],
DHCPv6 [RFC3315], stateless DHCPv6 [RFC3736].
-------------------------------------------------------
3)
A method to represent IPv4/IPv6 AR information (including security
associations to authenticate the AR information that will prevent
address masquerading [RFC3756]).
- s/associations/mechanisms/.
-------------------------------------------------------
4)
Re-wording to avoid the ambiguity in the text:
The goal of this multicast address resolution is to allow a
Receiver to associate an IPv4 or IPv6 multicast address with
a specific TS Logical Channel and the corresponding TS Multiplex.
-------------------------------------------------------
5)
Re-wording
SEND does not require the configuration of per-host keys and can co-
exist with the use of both SEND and insecure ND on the same link.
-------------------------------------------------------
6)
>> 5.5 DHCP Tuning
>
>
> This section does not talk about what happens
> to DHCP when the link is not bidirectional.
>
You are correct. If you have only uni-directional support at the IP
layer, can you use DHCP?
- I am note sure what you are asking? - Can you clarify.
-------------------------------------------------------
7)
>> The IPv6 ND protocol is supported. The protocol uses a block of
IPv6 multicast addresses, which need to be carried by the L2
network. The protocol does not require specification of a MAC source
address, although this is required for a node to participate in
Duplicate Address Detection (DAD) [RFC2462].
Updated sections that describe DAD issues to be clearer that this
arises when there is no MAC source address, or the bridge does not
filter based on source addresses.
-------------------------------------------------------
8)
>
>> Since there is no MAC/NPA address in the SNDU, ARP and NDP are
not required.
>
> ND for address resolution is not needed, but it may still be
needed for DAD or NUD.
Added:
The ND Protocol is also used to perform other functions beyond
address resolution, including Router Solicitation / Advertisement,
Duplicate Address Detection (DAD), Neighbor Unreachability Detection
(NUD), Redirect. These functions are useful for hosts, even when
address resolution is not required.
And then in this place:
The ND protocol may still be required to support DAD, and other
network functions. However, since there is no MAC source address,
there is no way for a system to differentiate DAD packets sent by
itself from those that may have been sent by another system with the
same L3 address, DAD therefore can not be used in topologies where
this L2 forwarding may occur (e.g. UDLR).
-------------------------------------------------------
9)
>
>> 6.1 ULE without a destination MAC/NPA address (D=1)
>
> The other sections except this talks about the need to support
multicast. But it seems that for ND to work multicast will be
required for the RAs to reach the hosts, as well as for DAD.
>
Fixed.
-------------------------------------------------------
10)
>> This document has reviewed the status of these
>> current address resolution mechanisms in MPEG-2
>> transmission networks and defined their usage.
>
>
>
> It is fine to review existing mechanisms. But I am concerned that
this document does not really in detail "define usage". I'm not sure
I could implement anything based on this, though it is possible that
the references provide additional information.
>
What seems to be missing?
Bridging over MPE/LLC is currently under-specified. Therefore
implementations may vary, and it should NOT be assumed that frames
sent using the Receiver's MAC address are necessarily delivered to
the Receiver's IP stack.
[>>> NOTE to RFC Editor: End of appendix] [>>> NOTE to RFC Editor: End of appendix]
 End of changes. 36 change blocks. 
333 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/