The IP Over NBMA (ION) Archive

[James T Smith <jtsmith@gte.com>]

At 08:21 AM 9/27/96 PDT, Yakov Rekhter wrote:
>Eric,
>
>>         I read you draft (draft-rfced-info-rekhter-00.txt).  Nice
piece
>> of work!  Very informative.
>
>Thanks !!!
>  
>>         As you, yourself pointed out, label-swapping is done by ATM
>> switches whenever they transfer a cell from one interface to 
another.
>
>That is correct. However, with ATM a label (VCI/VPI) is associated
>with a given src/dst pair. In contrast, forwarding granularity
>associated with a single tag is not constrained to a src/dst pair.
>For example, a tag could be associated with a group of destinations
>(a route).
>
>> Label-swapping is also done - at the network layer - by routers as
>> they forward packets.  
>
>Would you please explain what is exactly "label-swapped" in an IP
>header  when a router forwards an IP packet ?
>
>>         Speaking of tag-switching at the network layer, how is that
>> different than what Isilon switches do?  As I understand it, they do
>> switching at the IP (Network, right?) layer and I'd be very 
surprised
>> if they don't use VPI/VCI-like tags in doing it.
>
>There are several differences between tag switching and Ipsilon IP
>switching. For one thing, tag switching supports much broader
>spectrum of forwarding granularities than Ipsilon IP switching.
>Another difference is that with Ipsilon IP switching creation of
>"VPI/VCI-like tags" is traffic driven, while with tag switching tags 
>are created as a "by-product" of routing. There are other differences
>as well, but to keep this short I wouldn't go into more details.
>
>>         Anyways, I appreciate the timely information provided in 
this
>> internet draft.
>
>If you'd like to get more info on tag switching I would suggest
>to join tagswitching mailing list.
>
>Yakov.
>
>

I have joined the 'list' as well as read the web articles, etc.

I can hardly wait for the email's to begin pouring into the tagswitch
listserv.

I would like a discussion of the technical 'merits' of the two 
approaches [not of specific products, which we know are going to
evolve over time.]

Ipsilon's 'approach' maps nicely to other 'routed' protocols, and
to other 'switching matrix's' [even to SONET, etc.]

One thing that concerns me in the Cisco approach is the impression
that circuits [vc's] are 'tied-up' ,e.g., pvc's permanently available
for 'use' by the router.  The dynamics of the Ipsilon approach to 
provision svc's as needed seems to be a better use of limited 
resources.

Also, what is required [if indeed you envision it happening] to achieve
a 'cut-through' so that 'flow-processing' can really occur.  

By the way, the determination of when and what type of 'svc' to use 
is quite flexible with the Ipsilon approach.  Their method seems to
be a much cleaner decoupling of the 'router' and the 'switch' functions
than what I see in your documents.

Please provide a more 'strategic' view of your methodology.


Thanks very much.

======================================================
|       James T Smith            GTE Telephone       |
|  Senior Systems Architect   700 Hidden Ridge Rd    |
|      jtsmith@gte.com              HQW02J62         |
| 972-718-6564, FAX 718-6398   Irving, TX  75038     |
======================================================
_
For God so loved the world, that           | |
He gave His only begotten son that      ___| |___
whosoever believeth in Him, should     |___   ___|
not perish, but have everlasting life.     | |
| |
- John 3:16 -                              | |
|_|