Re: [RE] Stream identification at the MAC SAP
Michael, I am not sure why you say "[MJT] Yes, but this is strictly a end-point to end-point reservation. The network does not participate in the admission control//resource allocation stuff. " However, rfc 2205 says:
1. Introduction
This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93, RFC 1633]. The
RSVP protocol is used by a host to request specific qualities of
service from the network for particular application data streams or
flows. RSVP is also used by routers to deliver quality-of-service
(QoS) requests to all nodes along the path(s) of the flows and to
establish and maintain state to provide the requested service. RSVP
requests will generally result in resources being reserved in each
node along the data path.
Clearly intermediate nodes (routers) participate in the reservation process. The reason I brought this up was in response to the comment:
> None of the higher layer services running on
> ethernet/802(anything)/IP have any idea what to do with isochronous
> data ... so it is not surprising that there are no service parameters that deal with
> this.
Bill
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On Behalf Of Michael Johas Teener
Sent: Thursday, November 11, 2004 3:33 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
Comments to your comments ...
On 11/11/04 10:41 AM, "Shvodian William-r63101"
<bill.shvodian@FREESCALE.COM> wrote:
> Just an opinion, but ...
>
> 1. None of the higher layer services running on
> ethernet/802(anything)/IP have any idea what to do with isochronous
> data ... so it is not surprising that there are no service parameters that deal with this.
>
[Bill Shvodian] I don't think that is quite true. RSVP can be used to reserve bandwidth for a stream. From rfc 2205: "An RSVP session is defined by the triple: (DestAddress, ProtocolId [, DstPort])." This information could be used to identify an isochronous strream.
[MJT] Yes, but this is strictly a end-point to end-point reservation. The network does not participate in the admission control//resource allocation stuff. RSVP/RTP/RTCP things make all kinds of assumptions (basically that the network is IP only and is basically best-effort-only). ... and yes, the "ProtocolId, DestPort" pair *can* be used for stream identification ... but this is getting way beyond an 802 disscussion so I think we should just drop it for now.
2. At the guts of ResE, I expect we will need a unique EtherType to indicate an isochronous packet, just like you do for MAC control frames.
[Bill Shvodian] Identifying it as isochronous is one thing. Identifying
which stream is another. You may have two video streams and multiple audio streams between two nodes, but since the reservations and treatment may be different depending on the type of stream.
[MJT] The stream identification is indeed something that needs to be done, but I think the existing 802.2 SAP IDs are way too small. Isoch stream IDs should be fairly robust. I would argue that they should be identified by a multicast destination address ... on 802 this would allow up to 2^42 streams (less all those used for other purposes).
3. I expect there will have to be a NEW service interface for isochronous data (yet another reason for this to be done in 802.3). This might look just like the existing MA-UNITDATA.request, except with scheduling parameter(s).
[Bill Shvodian] I agree. I just wish that 802.2 had agreed to make the change so that ALL 802 standards would use the same defined parameters, rather than having one for RE, one for 802.11e, one for 802.15.3, etc, etc.
[MJT] Perhaps so. On the other hand, do you think we could use a SNAP header to build an 802.3-specific method for labeling Isoch protocols? I could imagine one that is used to tag all IEC 61883-type packets (the normal tagging and formatting system for consumer-electronics type streams in 1394).
--
---------------------------------------------------------------
Michael D. Johas Teener http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
--------------------- www.plumblinks.com ----------------------