Subject: Document Action: 'Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks' to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 02 Apr 2007 14:29:38 -0400

The IESG has approved the following document:

- 'Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks '
   <draft-ietf-ipdvb-ar-06.txt> as an Informational RFC

This document is the product of the IP over DVB Working Group. 

The IESG contact persons are Mark Townsley and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-06.txt

- Technical Summary

This document describes the process of binding/associating IPv4/IPv6
addresses with MPEG-2 Transport Streams (TS). This procedure is
known as Address Resolution (AR), or Neighbour Discovery (ND). Such
address resolution complements the higher layer resource discovery
tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet
ID (PID) value and a specific Transmission Multiplex. The document
reviews current methods appropriate to a range of technologies (DVB,
ATSC, DOCSIS, and variants). It also describes the interaction with
well-known protocols for address management including DHCP, ARP, and
the ND protocol, and provides guidance on usage.

- Working Group Summary

This document is a chartered item of the ipdvb WG. The document provides
a description of the mechanisms required to provide AR within an
MPEG-2 network, and how to achieve operational networks using
IETF-defined methods that work with large numbers of receivers and in
particular can accommodate the large(r) link delay. The charter item
states:

"Provide an Informational RFC describing a framework for unicast and
multicast address resolution over MPEG-2 transmission networks. The
document will describe options for the address resolution process,
relating these to appropriate usage scenarios and suggesting
appropriate protocol mechanisms for both the existing Multi-Protocol
Encapsulation (MPE) and the efficient encapsulation (2). Consideration
will be paid to existing standards, and the cases for IPv6 and IPv4
will be described."

The document also provides specific guidance for UDLR when used with DVB
networks and has references the specific case of DOCSIS. The advice and
issues described may also be applicable to other L2 networks.

- Protocol Quality

The document does not define a new protocol. It describes issues and
appropriate tuning for deployment of IETF and non-IETF protocols to
deliver an IP service over MPEG-2 based networks.

Note to RFC Editor
 
-------
Abstract
- Remove final clause of last sentence.
OLD:
   It also describes the interaction with
   well-known protocols for address management including DHCP, ARP, and
   the ND protocol, and provides guidance on usage.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NEW:
   It also describes the interaction with
   well-known protocols for address management including DHCP, ARP, and
   the ND protocol.
-------
Introduction 
INSERT the following new paragraph at the start of the Introduction (from
the abstract), before all others.
AFTER:
  1. Introduction
NEW:
   This document describes the process of binding/associating IPv4/IPv6
   addresses with MPEG-2 Transport Streams (TS). This procedure is
   known as Address Resolution (AR), or Neighbour Discovery (ND). Such
   address resolution complements the higher layer resource discovery
   tools that are used to advertise IP sessions. The document
   reviews current methods appropriate to a range of technologies (DVB,
   ATSC, DOCSIS, and variants). It also describes the interaction with
   well-known protocols for address management including DHCP, ARP, and
   the ND protocol.
----
Introduction 
- Remove definition.
OLD:
   The MPEG-2 Transport Stream (TS) provides a
              ^^^^^^^^^^^^^^^^^^  ^
NEW:
   The MPEG-2 TS provides a
----
Introduction 
- Remove definition.
OLD:
   used. This document calls this mapping an Address Resolution (AR)
                                             ^^^^^^^^^^^^^^^^^^^^  ^
NEW:
   used. This document calls this mapping an AR
----Section 6, Pqra 2. Final Sentence.
DELETE:
   In this way,
   all Receivers belonging to a network will Receive the same set of
   multicast/broadcast messages.
----
Section 6, After Para 2
INSERT new paragraphs after above deleted text:

  All Receivers in an IP network must receive all IP packets that use
  a broadcast (directed to all systems in the IP network) or
  local-scope multicast (section 3) address. Packets with these
  addresses are 
  used by many IP-based protocols including service discovery, IP AR,
  routing protocols. Systems that fail to receive these packets can
  suffer connectivity failure or incorrect behaviour (e.g. may be unable
to
  participate in IP-based discovery, configuration, routing, and
  announcement protocols).

  Consistent delivery can be ensured by transmitting link-local multicast

  or broadcast packets using the same Stream that is used for unicast
  packets directed to this network.

  A Receiver could simultaneously use more than one L2 AR mechanism.
  This presents a potential conflict when the Receiver receives two
  different bindings for the same identifier. When multiple systems
  advertise AR bindings for the same identifiers (e.g. Encapsulators),
  these must therefore ensure advertised information is consistent.
  Conflicts may also arise when L2 protocols duplicate the
  functions of IP-based AR mechanisms.
----
Section 5.5 
OLD:
/ may be used over MPEG-2 Networks./
REPLACE BY:
/ may be used over MPEG-2 Networks with bi-directional connectivity./
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
----
Section 6 - add open bracket
OLD text:
    An Encapsulator must therefore use only one method e.g. ULE or MPE)
NEW, Add a bracket to this:
    An Encapsulator must therefore use only one method (e.g. ULE or MPE)
                                                       ^
----

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce