Re: Moving right along ... Switching Type

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Maarten:

Thank you for the reply. Some comments in line.

Maarten Vissers wrote:

> Sudheer,
>
> See in-line...
>
> Sudheer Dharanikota wrote:
> >
> > Hi Maarten:
> >
> > Following ASON model... I have noticed the assumption that a set of
> >  access groups will form a subnet if and only if they at at the same
> > layer. With this in mind I have few comments below...
> >
> > Maarten Vissers wrote:
> >
> > > In a layered network approach (e.g. ASON), the switching type is obsolete... the
> > > routing is performed within a single layer network, using the links (ITU-T term)
> > > that are available in that layer network.
> > >
> >
> > What do you mean switching type is obsolete? Does this mean you do not consider
> > it in G.7713 (DCM document)?
>
> I mean the switching type is not needed.
>
> G.7713 does not have a "switching type" parameter included. This information is
> implicitly present; each message is within the scope of a particular layer
> network.
>

I agree that G.7713 does not consider "switching type". There are many differences
between ASON model and GMPLS model here.

Some of  them may be "assertions" because of my view on the trend. I may be wrong.

1. For example your concept of layer and GMPLS concept of layer are different.
ITU considers sub-layers as routable layers. IETF on the other hand considers
OSI 7 layers as routable layers :-)

2. GMPLS assumes a single control plane for all types of layers where as ASON model
assumes control layer independence is possible for different layers.

3. ASON tries to hide or make the client and server layer information independent of
each other. GMPLS on the otherhand leaves this interaction flexible either through
"Forwarding Adjacencies" and/or using "switching type".

Sorry if I am reopening some of the ITU decisions here.. but it is possible to
achieve whatever you would like to achieve with layer independence in ASON
is a subset (in my opinion) of what GMPLS can do.

>
> >
> > >
> > > >From a layer network's perspective, nodes have just a single switching
> > > capability (i.e. of that layer network)... nodes who do not have that switching
> > > capabiltiy are invisible... and nodes with this and other switching capabilities
> > > will only be presented with this layer network's switching capability; the other
> > > switching capabilities are invisible.
> > >
> >
> > Does this mean a port  (to be precise an interface - IETF terminology) on a node
> > with multiple switching capabilities (reconfigurable adaptation functions :-)) will
> > be part of multiple subnetworks?
>
> Such port will/may be part of:
>
> - multiple layer networks; e.g. a STM-N port supporting VC-3, VC-4 and VC-4-4c
> is part of the VC-3 layer network, the VC-4 layer network and the VC-4-4c layer
> network.
> To reduce complexity, it is possible to develop one protocol carrying the
> messages for all HOVC/STS layer networks. Then there will be a 1-to-1 relation
> between port and protocol. We have to address this in the coming period when
> working on the protocol specific implementation specifications.
>

THis is the approach taken by GMPLS. 1 port 1 protocol. This can be achieved
through switching type. Let me qualify my statement...

1. When there is not adoptation need to be done....

    If the customre always wants to take only GigE ports and some of the intermediate
    devices support an adoptation of GigE <-> SONET then using "switching type" one
    can decide the correct path and encapsulation before establishing the path. This is
    a major achiecvement in propagating "multiple switching types" (in my opinion). Here
    I am probably rephrasing what Yakov and John have already mentioned.

2. In cases where adoptation need to be performed (either due to non-availability of
    an encapsulation or an intentional need of an encapsulation adoptation)...

    This is the case you folks eloquently communicated in the last few days.

   In this case we still need "switching type" to select the path and some additional
   information to allow changing of encapsulation or extension to the path vector to
   impose/signal the encapsulation adoptation at the intermediate nodes. Remember
   one another way to achieve the functionality is using forwarding adjacencies.

>
> - multiple subnetworks; e.g. a STM-64 port with 64 VC-4 connection points
> could have all 64 VC-4 CPs located within one VC-4 subnetwork, or
> could have 32 VC-4 CPs in subnetwork 1, 10 in subnetwork 2, 7 in subnetwork 3,
> etc.
> This latter is the case when VC-4 VPNs are present... e.g. the first 32 VC-4 CPs
> are allocated to the Switched Public Network subnetwork, 10 to the non-switched
> subnetwork and the other VC-4 CPs are allocated to a number of VC-4 switched
> VPNs.
>

IMHO, VPN is a different animal and has very little to do with the "switching type".
Especially in the scenario you have mentioned.

Regards,

sudheer

>
> Note - If these VPNs are dedicated VPNs (i.e. VC-4 CPs are exclusively allocated
> to one VPN), each VPN has its own dedicated Connection Controller (CC), Route
> Controller (RC) and Link Resource Managers (LRM) components (refer to G.8080) as
> well as its own dedicated links.
>
> Regards,
>
> Maarten
>
> >
> > >
> > > Perhaps a additional sentence should be added to clarify that the switching type
> > > is obsolete for the case of a layered network approach.
> > >
> >
> > I would not do this in such a hurry :-)
> >
> > Regards,
> >
> > sudheer
> >
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Dimitri Papadimitriou wrote:
> > > >
> > > > Hi,
> > > >
> > > > We have two approaches either "traffic-parameters" are used
> > > > (in SENDER_TSPEC) then i think the Switching Type capability
> > > > is useless or they aren't then such field could be optionaly
> > > > used when applicable (some examples are given in the routing
> > > > document).
> > > >
> > > > Wouldn't be the right way to proceed by defining an "unknown"
> > > > or "unspecified" value used when "traffic-parameters" are
> > > > included within the Path Message and optional use the ones
> > > > proposed in the current version of the specification when they
> > > > aren't. This field is thus optional and MUST only be used when
> > > > traffic parameters are not defined. I think this solves both
> > > > approaches.
> > > >
> > > > I think that also some additional text is needed in order to
> > > > clarify the semantic; the following one can be proposed (after
> > > > having discussed with some individuals):
> > > > "The Switching Type field is provided to allow nodes having
> > > > multiple switching layer capabilities to indicate their
> > > > preference. This field should only be used to indicate the
> > > > link switching preference but not end-to-end switching
> > > > preference".
> > > >
> > > > Notice that some proposal concerning the applicability scope
> > > > have been proposed but never really committed within the I-D.
> > > >
> > > > Cheers,
> > > > - dimitri.
> > > >
> > > > Zhi-Wei Lin wrote:
> > > > >
> > > > > Hi John,
> > > > >
> > > > > > <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.
> > > > > >
> > > > >
> > > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > > different switching capabilities on each side and the possible
> > > > > connections and then demonstrate that what switching capability is
> > > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > > encoding type says and the sender_tspec says is what the switching type
> > > > > used (I'm lazy, it takes too long to run through all the combinations)</z>
> > > > >
> > > > > >
> > > > > > 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>Well, for example, you have a SONET network that can provide STS-48c,
> > > > > and it goes through an all-optical network that can provide OCh1 (2.5G
> > > > > service). In the SONET network it switches the STS-48c layer, while in
> > > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > > > > connection, where one part of network may work PDH-based and switching
> > > > > E1 while another part may be SDH-based and switching VC-12, but the
> > > > > connection or service is essentially the same. They're not really
> > > > > client-server layers but similar layers from different technologies...</z>
> > > > >
> > > > > > <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.
> > > > > >
> > > > >
> > > > > <z>Maybe this is one where we need to ask individuals with operational
> > > > > experience and have some experience with service provisioning whether
> > > > > having one end with Ethernet and another end with OC-48 sounds like a
> > > > > configuration that makes sense?
> > > > >
> > > > > Again, the point here is that if this doesn't make sense, then
> > > > > essentially what you have is multiple switched networks, each serving
> > > > > one particular type of customer interface, i.e., a switched network for
> > > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > > >
> > > > > Is this one of those "violent agreements" where we're concentrating on
> > > > > two different levels but saying the same thing?</z>
begin:vcard 
n:Dharanikota;Sudheer
x-mozilla-html:FALSE
url:http://www.cs.odu.edu/~sudheer
org:Nayna Networks Inc.
version:2.1
email;internet:sudheer@nayna.com
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0A;Milpitas;CA;95035;USA
fn:Sudheer Dharanikota
end:vcard