Re: [RE] Stream identification at the MAC SAP
Comments below.
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
On Behalf Of Shvodian William-r63101
Sent: Thursday, November 11, 2004 1:08 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: 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.
<DC> There used to be a lot of mis-conception about RSVP and QoS. IMHO a
signaling protocol to intermediate routers. How these routers react to a
given RSVP message is totally up to the router vendor. So RSVP supports
the "request for QoS" not QoS itself.
However, I don't think we should rely on IP layer protocols to support
iso-traffic. There are plenty of BPDU based protocols out there, so why
not have our own (provided 802.1 acquiesce)?
Dirceu <DC/>
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 ----------------------