[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF-61 DRAFT NOTES.
The following text provides the draft notes. Thanks are due to our two
note-takers: Carsten Bormann and Jörg Ott. These are formatted for the
proceedings of IETF-61. Please could people in the Working Group check them,
and send any corrections/additions a.s.a.p..
Best wishes,
Gorry Fairhurst
----------
Minutes of the IPDVB WG (IETF-61)
---------------------------------
Chair: Gorry Fairhurst (gorry@erg.abdn.ac.uk)
Notes by Carsten Bormann and Jörg Ott
1. Agenda Bashing (Gorry Fairhurst)
The IPDVB WG met once at the 61st IETF for a two-hour slot. The
meeting was attended by approximately 30 participants. The proposed
agenda was accepted (with one addition made later during the meeting). Gorry
noted that the IETF-hosted ftp archive of the mailing list for the
IPDVB WG is now operational, as a backup to the existing WG archive.
2. Working Group Status and Plans (Gorry Fairhurst)
Gorry provided an overview of the current status of the documents and
the working group as a whole. The two current WG drafts are nearing
completion; the generic parts of the XULE draft were integrated into
the ULE draft, but specific XULE features were left out (these are a
possible item of future work within this group). The working
group has successfully completed two milestones and is slightly
lagging behind on four others. The main focus of the meeting is on
new work items: address resolution and XML receiver configuration.
3. Requirements/Framework (Marie-Jose Montpetit)
draft-ietf-arch-01.txt
Marie-José presented the status of the architecture document. Its main
purpose is to establish terminology, define implementation scenarios
(richer than just use cases), discuss the relationship to existing
work (ATSC, DVB, ISO, etc.), and to establish requirements for the WG.
She noted that the scope of the work has expanded from a focus on
encapsulation to a rather complete system solution, and from satellite
links to a broader coverage including terrestrial networks. After
briefly reviewing the scenarios, Marie-José discussed the changes
since the last revision and the comments raised during WGLC. Besides
a few nits, only one technical open issue remains: Shall link security
be mandatory or optional? Once this issue is resolved, the updated
document will be posted and shall be considered for publication as
Informational RFC.
Comments from the group clearly indicated that security should not be
mandated: Layer 3 security is available, so that specific link layer
mechanisms are not needed in many cases. Also, security is highly
application-dependent. Link-layer security would require key
management to be defined. Gorry noted that those comments are in
favor of the current text.
The draft will be updated to incorporate all comments received on the
list and during the meeting, and passed to the AD for review.
4. Ultra Lightweight Encapsulation (Gorry Fairhurst)
draft-ietf-ule-02.txt
Gorry presented an update to the ULE specification ID and
reviewed the -- largely minor -- changes to the document. The major
technical modification is the inclusion of the ULE extension
mechanisms in section 5. Gorry noted an issue in the processing
rules: What to do when the CRC fails in a previous packed SNDU? Two
options were available: a) discard corrupted SNDU and enter idle state
(conservative - required in previous revisions of the ULE draft);
b) discard corrupted SNDU and continue unpacking next (liberal).
Commenters pointed out that this is a local implementation
decision and that both can be allowed. The authors plan to look at
the current text, to examine the implications on interoperability
from relaxing the wording. There was also a request that the draft
should be updated to to say why this issue needs consideration.
This issue was taken to the list for further discussion.
Known ULE implementations are listed at:
http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html; information about
other implementations is solicited so that the list can be updated.
The IANA consideration section has been updated. The group needs to
decide on the policy for registrations of new ULE extension headers:
should an RFC suffice or should standards track be required? Comments
were made that a strong specification level (i.e., standards track)
should be required (only a few extensions are envisioned anyway, this
should not be issue).
It is planned to have a new revision of the draft available by the end
of November. It should then be ready for WGLC.
5. ULE Extension Headers (Gorry Fairhurst)
draft-collini-xule-00.txt
Gorry briefly outlined the evolution of the ULE extension headers
draft since the last IETF. Its main features were defining the
extension header format that is now included in the base ULE spec.
Hence, there is little reason to the draft around. Gorry proposed to
simply let it expire -- which was accepted.
6. Address Resolution (Marie-Jose Montpetit)
draft-fair-ipdvb-ar-02.txt
Marie-José presents the draft on address resolution for IP/DVB. It
is based on the requirements for address resolution described in the
architecture draft. Table-based mechanisms for IP-to-MPEG-2 address
and IP-to-MAC address mapping will be reviewed (including
known/solved issues). The changes since the last revision include:
splitting the document into two parts to strictly separate the review
of existing stuff from a newly proposed protocol; adding another
co-author (Hidetaka Izumiyama); adding the Wishnet experiments with
IPv6; and various editorial changes.
Marie-José solicits input from the working group on more specific
implementations: INT usage for IP/PID; IP/MAC resolution; DHCP and
NAT; DVB-RCS use cases (e.g. MMT); MHP/OpenCable use cases (AIT, etc.).
A new revision of the document will be made available by the end of
December 2004. A document in this area should become a WG item in
the mid-term.
IETF protocol dependencies and issues are important: DHCP, NAT, UDLR,
ARP, and ND. In the discussion, one question asked why NATs were
considered relevant to address resolution; the implications on other
mechanisms needed to be considereted, but the address
translation itself is a different issue. Marie-José said that,
at this time, the authors were collecting information that may be
relevant (and this may have an impact on how mapping tables are
ultimately built). The potential relevance of the IETF BEHAVE WG was
also mentioned, but the work in BEHAVE may be too specific.
7. XML for Receiver AR Config (Martin Stiemerling)
Martin presented an overview of the design space for configuring IPDVB
receivers and particularly discussed the pros and cons of XML-based
approaches. The problem space to be solved includes IP address and
stack configuration, service-related configuration, among others. He
identified three issues to discuss: the configuration scenarios, what
exactly to configure, and which mechanisms to apply for a configuration.
As related areas, Martin mentioned IPCDN, DOCSIS, and DVB (with SI
tables) layer 2 and DHC, NETCONF, and basic IP mechanisms (such as
neighbor discovery) at layer 3(+). Some discussion arose concerning
why XML should be used and why tables are suggested instead of the
existing IP mechanisms. Those issues are addressed later.
Martin described two configuration scenarios: 1) in the IP
configuration scenario, underlying (DVB) mechanisms are already up and
running and configuration essentially comprises IP-layer parameters.
2) In the complete bootstrap case, the configuration must start from
scratch and requires to configure the DVB layer as well.
Martin also identified a set of issues to be discussed, including:
Who is in control of the receiver? - several scenarios exist,
some controlled by an operator, some configured by a user.
Scale: The difference in scale (10^5 receivers)
compared to a few for NETCONF and 10^3 for IPCDN.
Martin concluded in stating that is too early to define parameters.
Rather, usage scenarios need to be defined, then related techniques
should be explored to learn from these.
Commenters recommended that the WG first looked at how to use
existing protocols (that may also be used in a uni-directional way),
and see how much can be done using existing mechanisms (this may also
depend on whether there is also Internet connectivity via other links,
or only via a single link). Some changes may be needed to the existing
protocols. It was noted that the information required can vary between
scenarios.
Comments were made that it is important to keep things simple. Some
further debate arose around the merits of and issues with using XML
(at this layer). Marie-José also pointed to a draft on address
resolution and configuration based upon XML (which she presented later).
A separation was suggested between "Address Resolution (identification
of sender/receiver)" and "Address Mapping (to lower layers)".
8. Receiver AR Config/Protocol (Gorry Fairhurst, Marie-José Montpetit,
Joerg Ott)
draft-mjm-ipdvb-config-00.txt (see mailing list)
Later published as: draft-montpetit-ipdvb-config-00.txt
draft-ietf-mmusic-img-req-07.txt
draft-ietf-mmusic-img-framework-08.txt
Marie-José introduced an XML-based AR configuration protocol. This
approach built upon existing table-based mechanisms, but used XML
syntax. It defines a simple autoconf protocol for extended AR records
and builds on existing protocols where possible. She discussed a
number of requirements, including: extensible syntax (e.g., to
represent future fields), optimizations for large-scale multicast, and
support for source/destination scoping. The presentation suggested an
XML syntax. Delivery mechanisms may comprise SOAP, UDP, and SIP.
Marie-José said there w3as running code for the proposed solution and
there is interest and participation from the different industries that
make up the MPEG-2 community.
Joerg Ott pointed to work on Internet Media Guides (IMG) that is
on-going in MMUSIC (in the IETF Transport Area) that may be suitable
for higher layer service announcement aspects. This was briefly
presented in a -- dynamically added -- presentation after the one
given by Marie-José.
Joerg Ott presented an overview of the work on Internet Media Guides
(IMGs) as presently undertaken in the MMUSIC WG (where it was started
some 1.5 years ago). The work is motivated by the need to provide
powerful generic mechanisms for disseminating content and service
information in various networks (including DVB, UMTS, and plain IP
networks, among others).
The concept of IMGs defines mechanisms to communicate metadata (about
content, services, and also configurations) from one or more IMG sender
via zero, one, or more intermediaries (IMG transceivers) to any
number of IMG receivers. IMG metadata -- formats for which are not
defined in MMUSIC -- are encapsulated in IMG envelopes and transported
using different IMG operations: ANNOUNCE for multicast/broadcast
dissemination, QUERY/RESOLVE for receiver-side inquiries (polling)
to a server, and SUBSCRIBE/NOTIFY for asynchronous notifications.
These operations are realized using FLUTE, HTTP, and SIP, respectively.
As IMGs are agnostic to the content format, (XML or otherwise encoded)
high-level configuration information could be distributed via IMG
mechanisms. The reliable multicast support appears particularly
applicable for a DVB environment. Authentication of source is also important.
Comments from the audience suggest that this may be very applicable,
not necessarily at the IP layer (as Gorry pointed out). Joerg made
the point that this is clearly not meant for IP stack configuration,
but for higher layer information. Hence there is a "vertical" split
between IMG and DVB/IP layer config -- which is well-recognized. Arguments
were made that the address resolution mechanism should not reach too far up
into higher layer aspects, but be very restrictive. Some intermediate MPEG-2
devices currently have no IP-stack, and simple clients would be needed.
Higher layer aspects could be dealt with by work such as IMGs working with
other IETF WGs.
9. Review of Milestones (Gorry Fairhurst)
Gorry reviewed the WG milestones. The two initial milestones have been
met (for the architecture and the ULE document), but their completion
is lagging behind. While the address resolution is progressing, the
respective future milestones will likely need adjustment. These Charter
changes will be agreed with our responsible Area Director (Margaret).