RE: GMPLS Sonet extensions

["Bernstein, Greg" <GregB@ciena.com>]

Hi Maarten et. al., I had two cases in mind. You'll have to meet me halfway
on the terminology (I'm using SONET below in my examples).
(1) Signaling for each layer -- this can use a "common signaling" protocol
with different "objects" or "information element" particular to that layer.
This protocol would be used between the appropriate entities that control
the switching at that particular layer.  For example, say I want to switch
VT1.5s (a container for carrying T1s in SONET) then I would signal between
the VT1.5 switches along the path using this common protocol.  If I first
needed to connect some STS-1 paths between these VT1.5 switches then the
signaling protocol (with STS-1 descriptions in it) would be used between
these STS-1 switches.  Now if a vendor chooses to integrate STS-1 and VT1.5
switching in the same box its up to them whether they choose to separate
these signaling control entities or combine them into one entity.  The
logical layer model still stands.  I didn't assume any particular mechanism
for the signaling transport (except IP) since different layers/technologies
may have different mechanisms available, e.g., SONET's DCC.  I also didn't
want to dictate where the network engineering function resides, i.e., where
in the above example you'd figure out the best place to put the STS-1 paths
given locations of VT1.5 switches, traffic trends, SONET line capacities
etc. Is this what you are calling a LNTC?

(2) Routing for each layer -- Here things are a little less obvious to me.
Yes, I can run a separate instance of a route protocol for each layer but
can I keep things simpler and would it be truly simpler.  Back to the SONET
example.  For setting up STS-1 (or STS-Nc) connections I would want to know
about SONET line layer topology (via a link state route protocol).  For
setting up the VT1.5 connections I would want to know about the SONET STS-1
layer connectivity between the VT1.5 layer switches.  If one had a network
with switches with combined (multi-layer) switching capability then I could
see some advantages in combining these.  At a minimum I can see that the
network engineering function for the VT1.5 layer switches (the thing that
needs to set up the bandwidth between the VT1.5 layer switches) would want
to know about both layers (it must know about the SONET line layer).  This
is what motivates integrating multiple layers into a single instance of a
routing protocol. But what about more than two layers? How would a knowing
the DS0 connectivity/traffic trends be of use to the network engineering
function for STS-1 paths between VT1.5 switches? I don't think so since we
see this via the VT1.5 trends anyhow.  Similarly the properties of layers
below the SONET line layer should be already summarized via SRLG info so I'm
not sure that knowing the exact topology down at the waveband level is all
that helpful.  Kireeti (or Yakov) the forwarding adjacency concept was
introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this was
for MPLS within MPLS now we are talking multiplex hierarchies where the
entities at the different layers are very much different from each other.

Maarten, are we converging here (except for terminology of course)?

Greg B.



-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Tuesday, June 12, 2001 1:19 AM
To: Bernstein, Greg
Cc: Diego Caviglia; Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron;
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
> > > >