Re: GMPLS Sonet extensions

[Maarten Vissers <mvissers@lucent.com>]

Diego,

If we assume that e.g. LOVC-SCs communicate with other LOVC-SCs and that
HOVC-SCs communicate with other HOVC-SCs, then it seems not possible to
me (might be wrong) to aggregate LOVC information exchanged between
LOVC-SCs with HOVC information exchanged between HOVC-SCs in one and the
same message. Aggregation can be realised in this case by multiplexing
both information flows onto the same SCN only.

The SCN is a data network in which LOVC-SCs, HOVC-SCs, ODU1-SCs, etc are
endpoints. If this network is build up with e.g. MPLS connections we may
multiplex LOVC information flows with HOVC information flows over the
same MPLS connection (e.g. between A and B) if e.g. LOVC-SC and HOVC-SC
within network element A need to communicate with LOVC-SC and HOVC-SC in
network element B. But logically, there are a LOVC-SC-A to LOVC-SC-B
MPLS connection, a HOVC-SC-A to HOVC-SC-B MPLS connection and an NE-A to
NE-B MPLS aggregate connection.

Regards,

Maarten



Diego Caviglia wrote:
> 
> Maaeten,
> 
>                 In my understanding Greg's sentence (but of course the last word
> on  the  matter  of  his  sentence  is  up  to him) refers to the possibility of
> aggregating  information  from  different  layers in order to have less protocol
> instances than layers.
> 
> If we consider all the possible layers inside the TN we have:
> 
> 1.   LOVC
> 
> 2.   HOVC
> 
> 3.   ODU1
> 
> 4.   ODU2
> 
> 5.   ODU3
> 
> 6.   Lambda

I prefer to refer to the latter one as "OCh" (optical channel). A
"Lambda" is a representation of a tributary (i.e. frequency) slot in an
aggregate signal. Thus a Lambda is not a signal. 

"Lambda switching" is as such also impossible; instead the "optical
channel signal" (transported over a "lambda") is switched from a lambda
in the incoming aggregate signal to a lambda in the outgoing aggregate
signal (or to a single channel outgoing signal without lambda).

> 
> Moreover  we  have to take into account for Lambda switching purpose the type of
> the  fiber  (I  mean if the fiber is G.655, G.653, G.652 and maybe the vendor of
> the fiber) and for diversity routing purpose the duct layer.
> 
> Do  we  need  to  aggregate  information  from  these layers? If so how could we
> aggregate layers?
> 
> Is  OSPF/IS-IS with extension the right choice in this layered environment or do
> we have to move to another routing protocol?
> 
> The  routing  protocol(s) have to cope with lots of constraints and with lots of
> problems  that  were not in the "flat" IP networks for which they were designed.
> e.g.  can a LOVC request trigger a HOVC trail creation? Repeating the process it
> could  be  possible  that  a  LOVC  request triggers a Lambda trail that from an
> operator perspective, which I suppose is not desirable.

Correct. My example is a DS1 (1.5M) connection request creating a 40G
ODU3 trail; see ftp://ftp.t1.org/T1X1/X1.5/1x151260.doc

Regards,

Maarten

> 
> Best regards.
> 
> Diego
> 
> Maarten Vissers <mvissers@lucent.com> on 12/06/2001 10.18.38
> 
> 
> 
> 
> 
> 
> 
>  To:      "Bernstein, Greg" <GregB@ciena.com>
> 
>  cc:      Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda
>           <yone@japan-telecom.co.jp>, v.sharma@ieee.org,
>           Jimmy Gendron <jgendron@hyperchip.com>,
>           ccamp@ops.ietf.org
> 
> 
> 
>  Subject: Re: GMPLS Sonet extensions
> 
> 
> Greg,
> 
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer protocol
> > instances than network layers.
> 
> I am not sure I understand the meaning of the last sentence... does it
> refer to:
> a common Signalling Communication Network (SCN) over which all
> signalling messages are transported for all layer networks?
> 
> The ASON model under definition shows per switched layer network a
> hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
> Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
> These SCs communicate with each other over the SCN. LOVC-SCs communicate
> with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
> communicate with other ODU1-SCs, etc to exchange link state/topology
> information (case of I-NNI), reachability information (case of E-NNI,
> UNI) and routing information (connection setup). This is at the moment
> also referred to as "intra-layer" information exchange.
> 
> For the case we decide that a Network Engineering agent is included in
> an SC, we will get also "inter-layer" information exchange. E.g.
> HOVC-SCs may also communicate with LOVC-SCs to provide reachability
> information for ports (e.g. STS1 and VC4 access groups) within the LOVC
> layer network. For the case we decide that Network Engineering agents
> are not part of the SC (but in a separate "layer network topology
> controller" (LNTC)), "inter-layer" information exchange will be between
> an SC and a LNTC. This latter model has a preference at the moment,
> while the two processes (SC: routing, LNTC: network topology) have a
> different scope.
> 
> Note - LNTC within one layer network have to communicate with each other
> also to build up an understanding of potential topology capabilities
> present in the layer network (or layer network partition the LNTC is
> responsible for).
> 
> Separate of the above, the ASON recommendations will specify the signal
> flow over inter domain interfaces where
> - a customer interconnects with an operator
> - two operators interconnect
> - two vendors interconnect.
> 
> Over these inter domain interfaces you have to comply to the signal
> (message) structure. For ASON networks this will be based on the layer
> network structure. Within one domain the same layer network structured
> approach may be used, or one may decide to create a "spaghetti mountain"
> in which the layer network structure is not adhered to. That's up to the
> individual vendor.
> 
> Regards,
> 
> Maarten
> 
> "Bernstein, Greg" wrote:
> >
> > Hi Maarten, Diego, et. al.
> > what's interesting here is the question of what do we mean by "its own
> > instance of a control plane"?  Obviously if we are setting up a LOVC (in
> > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to
> > those switches that are LOVC capable.  Other switches need not be involved.
> > If it turns out that the LOVC capable switches are not interconnected by a
> > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> > appropriate HOVC interconnecting the LOVC needs to be setup first.  In GMPLS
> > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> > switches before we set up the LOVC LSPs.
> >
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer protocol
> > instances than network layers.  Well actually as Maarten wrote in a recent
> > ITU document that we would be primarily interested in those layers involved
> > in dynamic switching/multiplexing.  Note that we've started to bring in
> > non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> > (the WDM--SONET example I always give).
> >
> > With the signaling protocol things are really separated by who is involved
> > in the signaling transaction.  In the routing case things are less clear,
> > i.e., who wants/needs to know information about other layers and what burden
> > does this present to the NEs and scalability.  Which layers can benefit by
> > integration...  I'll be updating the Optical inter-domain route requirements
> > draft soon (with others) and will be exploring some of these items in more
> > depth.
> >
> > (Terminology: LOVC := Lower order virtual container, SDH term that includes
> > signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> > the SDH hierarchy).
> >
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: Monday, June 11, 2001 7:46 AM
> > To: Diego Caviglia
> > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org
> > Subject: Re: GMPLS Sonet extensions
> >
> > Diego,
> >
> > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> > and OCh) will have its own (instance of) control plane.
> >
> > Each switched layer network runs a copy of the generic routing protocol;
> > it does so within the boundaries of the switched layer network.
> >
> > Within each switched layer network you will find UNI, E-NNI and I-NNI
> > interfaces due to partitioning of a switched layer network. Topology
> > information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> > the other hand only provide reachability information.
> >
> > For the case an MPLS router is from a different organisation than the
> > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> > interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> > the interface will be an MPLS-I-NNI.
> > For the server layers within the MPLS router (e.g. HOVC and STM-N
> > section layers) the interface relation is to be determined independent
> > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> > at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> > as at the HOVC layer entwork only reachability information is available
> > in the MPLS router (HOVC-E-NNI).
> >
> > The MPLS router should not be concerned at all about the routing of the
> > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> > between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> > link between is needed between MPLS router A and MPLS router B, router A
> > needs to have knowledge of router B's address/name only to request a
> > VC-4-16c/STS-48c connection through the transport network. The switched
> > HOVC (transport) network will take care of the connection setup.
> >
> > And even if two diverse routed connections are required (e.g. to support
> > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> > needs to request only the creation of 2 VC-4-16c connections with the
> > constraint of being diversely routed. The switched HOVC network will be
> > able to provide these two connections diversely routed between A and B
> > routers.
> >
> > At the moment, I recognise two connection types in a layer network:
> >         - native connections and
> >         - client connections.
> > Example: within a HOVC layer network a STS1 or VC-4 connection is a
> > native connection, and a DS3 connection or a LOVC link is a client
> > connection. A client connection is supported by the HOVC layer network
> > after adapting it to the layer network signal type (i.e. STS1 (to
> > support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> > can have a
> >         - 1:1,
> >         - 1:n,
> >         - n:1
> > relationship with the underlying layer network signal.
> > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> > relationship.
> >
> > With client connections, an I-NNI is almost per definition not possible
> > (you go outside the layer network). Nevertheless, some people consider
> > the special 1:1 case as an area where an I-NNI could be deployed; of
> > course not for the case of DS3 -> STS1, but for the case of
> > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> > HOVC layer network and a client signal to the OCh and ODU1 layer
> > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> > wavelenght it is easy to think to be within one and the same layer
> > network. Personally, I believe that such very special case looks much
> > brighter than it is in the long term. I.e. don't declare very special
> > cases to be the common ones; keep those as very special cases, best even
> > keep those as regular cases obeying to the generic rules.
> >
> > Client connections as such have UNI or E-NNI interface relationships
> > over which reachability information is offered at best. This is the case
> > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> > layer entwork) as well as "vertical client connections" (e.g. a LOVC
> > link over a HOVC/STS layer network).
> >
> > Regards,
> >
> > Maarten
> >
> > Diego Caviglia wrote:
> > >
> > > Maarten,
> > >                     I agree in principle with you but this means it would
> > be
> > > necessary to have a routing protocol for each layer doesn't it?
> > >
> > > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> > plane, your
> > > layered view of the network implies again the separation of the control
> > planes.
> > >
> > > The  Transport  Network is very different from a flat IP network and
> > layering in
> > > TN is implicit.
> > >
> > > If  I  understood your model correctly the MPLS Router only views, Access
> > Groups
> > > and  links  to  other  MPLS Routers. If there are free resources between
> > the two
> > > routers  the TE process calculates, accordingly to some rules, the best
> > path.
> >
> > Agree.
> >
> > > If
> > > there are no resources a call to the Network Engineering agent is
> > performed, the
> > > NE  makes a call to the TE of the SONET layer in order to provide a trail
> > to the
> > > MPLS layer (this procedure is repeated until available resources are
> > created for
> > > the MPLS router connection). This trail modifies the topology at the MPLS
> > layer.
> >
> > Agree. One note however, operators have indicated that they would like
> > to deploy policies in the NE agent which may include some thresholds,
> > before it decides to change the topology of the layer network. E.g.
> > topology is not extended unless X calls failed. On the other hand, the
> > NE agent may have scheduled topology changes; e.g. at the begin of busy
> > hour extra links are added or bandwidth of existing link is extended,
> > and at the end of busy hour the reverse is happening.
> >
> > >
> > > If  my  understanding is correct and we want to implement an automated TN
> > a sort
> > > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> >
> > UNI or E-NNI.
> >
> > >
> > > Maybe this will create some problems, on the other hand, as Maarten
> > pointed out,
> > > flat  networks  won't  work due the huge amount of routing information
> > that they
> > > have to carry.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > Maarten Vissers <mvissers@lucent.com> on 11/06/2001 13.16.52
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Susumu Yoneda <yone@japan-telecom.co.jp>
> > >
> > >  cc:      v.sharma@ieee.org, Jimmy Gendron
> > >           <jgendron@hyperchip.com>, ccamp@ops.ietf.org(bcc:
> > >           Diego Caviglia/MAIN/MC1)
> > >
> > >
> > >
> > >  Subject: Re: GMPLS Sonet extensions
> > >
> > >
> > > Sharma,
> > >
> > > "flat" set up is the route to disaster... simply consider a switched
> > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > > would get information of all these levels... an absolute disaster in a
> > > world wide switched transport network would be the result.
> > >
> > > Therefore, there is this layering in which a server layer network
> > > provides bandwidth to its client layer entworks. the client layer
> > > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > > can route their signals.
> > >
> > > A separate entity (I called it "network engineering") is looking over
> > > the shoulder of the call setup process to see if more bandwidth is
> > > needed and when it would be needed or not longer required. But today,
> > > this separate entity is not part of the control plane; it is in the
> > > management plane.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Susumu Yoneda wrote:
> > > >
> > > > Sharma,
> > > >
> > > > Thank you for letting me know your presentation material which looks
> > very
> > > > interesting. It seems to me that a layered setup would make a sense.
> > > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > > would not be seen by users?
> > > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com]
> > > > Sent: Saturday, June 09, 2001 11:06 AM
> > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org
> > > > Subject: RE: GMPLS Sonet extensions
> > > >
> > > > Jimmy, Susumu,
> > > >
> > > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > > have the same view of the network, you could compute an ERO at the
> > > > ingress router and have the PATH message follow the hop-by-hop route
> > > > to the egress router.
> > > > (Note, however, that the PATH message will travel
> > > > on the out-of-band IP control network; therefore, it would be
> > non-associated
> > > > signaling.)
> > > >
> > > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > > in fact, have to be shared by all nodes, since that is precisely what
> > > > the "peer model" implies.
> > > >
> > > > But you do have to be careful about what "LSP" you are requesting, since
> > the
> > > > characteristics of the requested LSP are not interpreted in the same way
> > by
> > > > the
> > > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > > different
> > > > way of defining a circuit than an IP router or an OXC.)
> > > > Therefore, one possibility would be to do a "layered setup", where an
> > LSP
> > > > at the lower layer is setup before the PATH message at the higher layer
> > > > is tunnelled over it or allowed to propagate further.
> > > >
> > > > For example, when the PATH message for the packet
> > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > > a corresponding SONET circuit between themselves, and then either tunnel
> > > > the PATH message for the packet LSP over this circuit, or (assuming your
> > > > out-of-band network), at that time, allow the PATH message for the
> > packet
> > > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > > channel, likewise, would be a recursive process, with the OXC first
> > setting
> > > > up an optical lightpath between themselves, and tunneling the request to
> > > > set up the SONET channel over it, once that lightpath is setup.)
> > > >
> > > > A more detailed discussion of this subject, with corresponding
> > animations
> > > > and figures, that you may also find helpful is available in a talk I
> > gave at
> > > > MPLSCon'01, and can be found at:
> > > > http://www.mplscon.com/missing_presentations.htm
> > > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > > >
> > > > -Vishal
> > > >
> > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > > [SMTP:yone@japan-telecom.co.jp]
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I also assume that there would be an out-of-band signalling network
> > based
> > > > on
> > > > > a suite of GMPLS protocols including LMP. I think there will be issues
> > to
> > > > > address whether all messages will be shared by all nodes, i.e router,
> > > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > > -------------------------------
> > > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > > Japan Telecom    fax +81 3 5540 8485
> > > > > Information & Communication Labs.
> > > > > e-mail  yone@japan-telecom.co.jp
> > > > > -------------------------------
> > > > > -----Original Message-----
> > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> > Behalf
> > > > Of
> > > > > Jimmy Gendron
> > > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > > To: 'ccamp@ops.ietf.org'
> > > > > Subject: GMPLS Sonet extensions
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I used to read almost all stuff regarding GMPLS since a week. I
> > understand
> > > > > most of the architecture, but I still have a question since the
> > beginning;
> > > > > as an unified control plane, how do the routing/signaling protocols
> > > > exchange
> > > > > informations on a configuration like this:
> > > > >
> > > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > > (Ingress)
> > > > >
> > > > > Its a basic point to point configuration, but it will allow me to
> > > > understand
> > > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> > the
> > > > two
> > > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > > (Assuming
> > > > > that we have an out-of-band IP control network running LMP)
> > > > >
> > > > > My guess is that the PATH message will leave the ingress router with a
> > > > PATH
> > > > > message with a calculated ERO. It assumes that the network is in
> > respect
> > > > > with the peer model...everyone have the same routing table and know
> > the
> > > > > actual network topology. So, my PATH message will follow the CSPF
> > (ERO)
> > > > and
> > > > > go to the egress router. Am I right?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jimmy Gendron
> > > > >
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard