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 12:54 PM
To: John Drake
Cc: 'Ben Mack-Crane'; Kireeti Kompella; ccamp@ops.ietf.org
Subject: Re: Moving right along ... Switching Type


Hi John,


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


<z>The section you mentioned, from what I can tell, is an example list 
of some possible combinations of different equipment functions. I see 
them as examples. But as I said, from routing perspective, it may make 
sense but not signaling. What you've pointed out is the routing document...
 From signaling perspective, if I removed the switching capability 
field, there is nothing lost...do you agree?


JD:  No.  I will try again. What you have to demonstrate is that for all
possible combinations of switching capabilities supported on a link, an
intermediate node can deduce, from other fields in the Path message, what
switching capability is desired.   


And if I removed the switching capability field, then it opens the door 
for the possibility where somewhere within my network I might change the 
switching type in order to satisfy a request (because the switching type 
requested is non-existent or exhausted).</z>


JD: Please give an example of where substituting one value of switching
capability for another in the middle of an LSP makes sense.   


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


<z>I think it does make sense. I think you have to assume that within 
the switched transport network there will be many kinds of interfaces 
connecting to the transport network. If you can't offer this capability, 
then essentially what you've done is segment the transport network into 
sub-networks based on what interfaces they have and only the like-type 
interfaces can connect to each other. If you look at the IP world, you 
might have a switch with 100 Mbps and another with 10 Mbps connected 
together and talking to each other without a problem. This is capability 
that is also needed, where one end could be 1 Gbps Ethernet and another 
end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no 
reason to restrict this). What really matters is that the service is 
delivered. Granted there will be some inefficiencies in this, but that's 
really a policy decision whether users are willing to accept this type 
of connection.</z>


JD:  What you're describing here is PSC LSPs and they work just fine.  What
you were describing in your previous example was an LSP, one end of which
was
PSC and the other end of which was TDM.  And that doesn't make 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.
> 


<z>Right. It's a tool to support these services</z>