The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Sep> msg00009



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Reply on Semi MAJOR (was Comments on Multicast Draft)

  • From: James Watt <james@newbridge.com>
  • Date: Mon, 25 Sep 1995 18:53:06 -0400 (EDT)
  • Cc: jhalpern@ca.newbridge.com, ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com, rolc@nexen.com
  • X-Orig-Sender: owner-rolc@nexen.com

Grenville Armitage writes:
+-----------
| ... edited version of an exchange between Joel and Grenville ...
|>>
|>>   If we consider that MARS is supposed to be a Multi-Protocol
|>>   mechanism, then the pkt$pro mechanism seems quite awkward.  Any
|>>   protocol that does not have an Ethertype needs to be "defined"
|>>   to have some other value.  If we used a different ID space,
|>>   we could avoid this problem.
|
| ...
|
|Taking off my artificial "IETF only" blinkers for a moment I could
|suggest that one solution would be for the IP-ATM working group
|to pre-delegate part of the ar$pro space to a group we know is hoping
|to interoperate (and who _will_ attempt to apply this spec to a
|non-ethertype protocol of interest):
|
|e.g. new text:
|
|      0x0000 to 0x03FF  Reserved for future use by the IETF.
|      0x0400 to 0x05FF  Designated for use by the ATM Forum.
|      0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.
+------
Or what about biting the bullet and using 6 bytes: one for an NLPID and
5 for the rest (e.g. SNAP when the NLPID = 80).  This should be enough
to cover anything and everything.

While I think of it, this applies to NHRP too...

Regards,
Comments ?
-james

____________________________________________________________________________
James W. Watt,     james@newbridge.com                   Ph: +1 613 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680