Re: Bringing the ARCH draft to WG Last Call

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Some thoughts are in-line:

Martin Stiemerling wrote:

> Hi,
>
> --On Mittwoch, 18. August 2004 6:51 Uhr -0400 Marie-Jose Montpetit 
> <mariejose.montpetit@verizon.net> wrote:
>
> | There are a few remainning outstanding issues before the ARCH draft 
> can be
> | brought to WGLC. These were briefly discussed at the IETF but need a 
> wider
> | discussion on the list.
> | 1. Should there be some requirements to allow end to end management of IP
> | flows
> | this would enable enable operators to better configure, verify and
> | distribute policies regarding specific flows; there is heritage there 
> from
> | the cable industry
>
> I currently have the problem to understand what exactly the end-to-end 
> management of IP flows is in the context of ipdvb. Management means too 
> many different things to people.  Could you give me a hint?

Edge-to-Edge, End-to-End ... These are always confusing terms. My take 
is something like: the ipdvb WG is to look at solutions that enable 
MPEG-2 transmission networks to be more fully integrated into IP 
networks as a subnetwork technology. E-to=E means from IP-router to 
IP-router or end-host to IP-router or IP-router to end-host.

The work includes seamless (where possible) support for IP network 
functions (IPv6, mobility, security, diffserv, MPLS(?), etc etc), more 
integrated operations (i.e. ability to interact/inform MPEG-2 
transmission network components such as encapsulators and receivers - to 
indicate the properties of the IP flows which they are to transport). 
Things to consider include, where policies and decisions made in using 
the MPEG-2 transmission network for specific IP flows (which specific 
PIDs are used, which encapsulation is used, which encaps options, which 
MPEG-2 QoS functions, priority, multicast config, etc).

It may be hard to cover all scenarios with a single set of protocols, 
and we need to be clear of the different usages. Getting the terminology 
correct will also be challenging.

> | 2. Should address resolution be used to map specific addresses to PIDs
> | with special features
> | This would allow to combine AR with resource management, load balancing
> | and QoS
>
> The Internet-style solution would be AR does AR, no more no less.  All 
> the other things belong into different protocols, it should be all 
> IETF-safe "Protocol do only things they are intended to do" and Keep it 
> Simple, Stupid (KISS).
Aha - but in MPEG-2 I see  "resolution" occurs at three levels

(i)   IP -> resolution to NPA/MAC address (as in ethernet);
(ii)  IP -> resolution to Packet ID (PID);
(iii) IP -> resolution to specific transmission multiplex/phy link.

The WG includes all of these as part of the "resolution" process.
- This was the intended scope of a WG AR draft.


>   Martin
>
> | 3. Should extension headers carry information about the cell content over
> | the MPEG-2 section of the network
> | There are multiple uses of that including flow management.
> |
> | In addition we will add a protocol stack to the draft to show where ULE
> | is.
> |
> | Since we would like to finalise this shortly I would appreciate comments
> | on these issues and closure before 6/25.
> |
> | Thanks
> |
> |
> | Marie-Jose Montpetit
> |
> |


Gorry