RE: Moving right along ... Switching Type

[John Drake <jdrake@calient.net>]

-----Original Message-----
From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
Sent: Wednesday, October 31, 2001 10:03 AM
To: John Drake
Cc: 'Ben Mack-Crane'; Kireeti Kompella; ccamp@ops.ietf.org
Subject: Re: Moving right along ... Switching Type


Hi John, comments in-line.


> I think I've mentioned this before, but I'll repeat myself. I think 
> switching capability may have be useful in identifying what is allowable 
> for routing purposes and for discovery purposes.
> 
> But once those are identified, signaling does not need to get involved.
> 
> JD:  This sounds like an assertion.  It would be helpful to see a detailed
> proposal that describes how an intermediate node controlling a link with
> multiple switching capabilities can determine what switching capability
> a given LSP wishes to use.
>  


<z>Sorry. I thought this was akin to "obvious to the informed reader". 
;-) Just kidding. Anyway, let's give an example...

The user has a router with OC-48 physical interface, and is capable of 
requesting STS-3c or STS-12c or STS-48c services across that interface. 
So now the router has three levels of switching capability within the 
TDM layer (as IETF defines the TDM layer).

Now also assume that the network as a whole can support packet 
switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, 
STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its 
interfaces can support multiples of these types.

However, even in this case, when the router makes a request, let's say 
it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST 
object, & the SENDER_TSPEC object tells you what switching to use. Thus 
when the network (intermediate nodes) receives these objects, it knows 
what switching to use and what signal is been received at the interface. 
Therefore the switching capability doesn't tell me anything that is not 
already present or not already known by the nodes (another assertion?).

Hope this was what you were looking for...</z>

JD:  What you give here is an example, not a design.  You need to enumerate
the procedure for all possible combinations of multiple switching
capabilities.
As a start I'd suggest going through the examples in
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt, 
Section 6.4.9.x.  To be clear, I am not saying that it is not possible
to derive a procedure for all possible combinations.  What I am saying
is that I don't know if it is possible, but I do know that specifying
switching capability works in all cases in a consistent manner.    


> You responded to Ben that the switching capability field is end-to-end 
> and does not change in intermediate nodes. Is this right?
> 
> JD:  As far as I know.
> 


<z>If that's the case, how would you support a non-homogenous 
(heterogenous?) connection? By that I mean at the source end it is one 
type of interface and at the destination end it is another type of 
interface and each end cannot support the other end's switching capability.

For example, at the source-end, the physical interface is a 1 Gb 
Ethernet. At the destination-end, the physical interface is an OC-48 
interface. In this example, the switching capability at the source may 
be PSC. However at the destination end the switching capability may be 
TDM. The service requested is to be able to transport a "100 Mbps date 
stream" from source to destination.


JD:  The endpoints of an LSP need to have a common understanding of the
multiplexing used on that LSP, so I don't think your example makes sense.


I think for this, what is important is that the service requested can be 
supported end-to-end, not the switching capability supported, nor the 
signal type supported. Switching and signal type are a means to support 
a service, not an end to itself.</z>


JD:  As far as I know, GMPLS doesn't deal with service definition.


> Zhi
> 
> 
> 
> John Drake wrote:
> 
> 
>>Ben,
>> 
>>I think part of the problem is that you also need to read the GMPLS
>>
> routing
> 
>>drafts:
>> 
>>
>>
>
http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> 
>> 
>>There are also comments in your text.
>> 
>>Thanks,
>> 
>>John
>>
>>-----Original Message-----
>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
>>Sent: Monday, October 29, 2001 9:53 AM
>>To: Kireeti Kompella
>>Cc: ccamp@ops.ietf.org
>>Subject: Re: Moving right along ... Switching Type
>>
>>
>>
>>In reviewing the GMPLS signaling drafts I have been unable to
>>get a clear understanding of the need for and use of the Switching
>>Type field in the Generalized Label Request object.
>>
>>
>>JD:  The Switching Type field is for handling the situation where there
>>are multiple switching capabilities per interface (see section 6.4.6 of
>>draft-ietf-ccamp-gmpls-routing-00.txt)
>>
>>
>>This appears to be an attempt to address LSP setup involving multiple
>>layer networks, but it does not adequately address the issues involved.
>>
>>
>>JD:  Would you please provide some additional prose explaining your
>>reasoning on this?
>>
>>
>>That it "Indicates the type of switching that should be performed on a
>>particular link." makes it seem to be a local concern, while others
>>have indicated it is an end-to-end field. For example, George Swallow
>>says "It is my understanding that for a given LSP it does not change, 
>>but is carried end-to-end and applies at all intermediate hops along 
>>the path."
>>
>>
>>JD:  I think George's interpretation is correct, and I don't think the
>>other text you quoted contradicts George.  If a given TE link supports
>>multiple switching types, the node controlling that link needs to know
>>what switching type a given LSP wants to use.  
>>
>>
>>As an end-to-end item I have trouble understanding how the originating
>>
> node
> 
>>would determine how to set this (on what basis one determines what
>>
> switching
> 
>>choice to make in all cases).  In fact, I'm not sure why the originating
>>node would care what type of switching is used as long as the LSP is
>>delivered
>>to the egress faithfully.
>>
>>
>>JD:  The orgin node uses the switching capability information in the link
>>state
>>database in its CSPF calculation to ensure that switching capability is
>>consistent
>>along the path of the LSP.  
>>
>>
>>Regards,
>>Ben Mack-Crane
>>
>>
>>
>