Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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 ----------------------