Re: GMPLS Sonet extensions

[Maarten Vissers <mvissers@lucent.com>]

Greg,

See my notes inline.

Regards,

Maarten
PS. ITU-T has created an open area to share information with IETF and
T1X1.5. for the moment access is limited via ftp client only. Work is
ongoing to provide web access as well.

> Host Name: ftp.itu.int
> Host Type: Unix (Standard)
> Remote Host Name: /tsg15opticaltransport
> Log in with your username and password
> Username: sg15opticalt
> Password: otxchange

In this open area you will find now 3 ASTN/ASON architecture document I
have created.
WD07 ASTN Layer Network Architecture - Multiplicity and interactions of
Traffic Engineering and Network Engineering processes
WD08 ASTN Layer Network Architecture 
WD20 ASTN/ASON Layer Network Architecture (view)



"Bernstein, Greg" wrote:
> 
> 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).

No problem, SONET terminology is well understood by me. :-)

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

We seem aligned here.

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

Partly aligned here... Within one vendor's subnetwork I agree that a
vendor may choose to do this. But when the other switch is outside that
vendor's subnetwork, the signaling protocol would have to meet the
standard interface specification, which for ASON will have separate
signalling control entities.

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

Yes, this is what I intend torefer to by LNTC. Note - LNTC is a new term
that came to my mind when creating the previous reply. During the
Q.12/15 meeting last week people indicated that we need alternative
terms for "traffic engineering" and "network engineering" in the way I
was using those. My "network engineering" is controlling to some extend
the layer network topology; of course it isn't capable to add extra
hardware or software to the network, but it can modify the topology by
adding/removing/increasing/shrinking links (G.805 terminology)). If you
can think of a better term for this, let me know. I am looking for a
better term for "traffic engineering" (in my definition) process.
Perhaps this should be split into two "controllers"; one concerned with
distributing reachability/topology information and link state
information, and another concerned with the actual route finding and
connection setup/release. Any suggestions?

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

You need to know the fabrics and the links between those fabrics. It is
irrelevant if those links are provided by SONET lines or something else.

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

You need to know the fabrics and the links between those fabrics. It is
irrelevant if those links are provided by SONET STS-1s or something
else. E.g. a VC-4, sub-STM-0 or sub-STS-1 interfaces, ATM (some
operators use ATM VCs to carry VT/LOVC signals) or MPLS (see ongoing
SONEt/SDH over MPLS work).

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

I have to disagree here. The network engineering function for the VT1.5
layer switches needs to know only 
- the set of VT1.5 layer network "S_LN" ports (refer to WD08 section 5,
figure 38) or "class D" ports (WD20, section 2.3, figure 3) that are
present in the VT1.5 switches
- the reachability information per (group of) port(s).

The network engineering function (or LNTC) decides on the available
information between which two VT1.5 switches a VT1.5 link is to be added
or extended. 
Once this is decided, the LNTC has to determine if this can be realised
by menas of a direct link (single hop) or if a multi-hop link is the
only possibility; in the latter case the two ports to be interconnected
can not reach each other directly.
Then, the VT1.5 LNTC requests the new VT1.5 link (or links) to be
created by its server layer(s) between the specific ports (or port
groups).

There is no need to know anything about the SONET line layer here.

Furthermore, you should consider that the network must perform its tasks
independent of the physical grouping of functions. I.e. the behaviour of
the network must be the same independent of the fact of VT1.5 fabrics
and STS fabrics are in separate equipment, or in the same equipment, or
a mix of both is present. 
You should not base your design on only one of the possible cases.

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

I have the feeling that you are almost coming to the same conclusion as
I am in the lines above. I.e. if you can do a good job at DS0 level
without having knowledge of underlying STS, line and below layers why
would one need to have line level knowledge when being at VT1.5 level?
If you don't need it at one place, you can apply the same mechanism at
other places and you don't need it at those places either.

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

Allow me a side step here... from a transport perspective MPLS is having
some unique characteristics: 
	"one technology, 
	 infinite number of layer networks, 
	 infinite number of connection monitoring levels (potential 
	 iff MPLS OAM is introduced)". 

E.g. as MPLS is connection oriented, I can use transport layer
terminology to describe the MPLS network architecture:
- the outer MPLS layer network connects to (non-MPLS) client layer
networks via adaptation functions
- adaptation functions to client layer networks can be of the 1:1 type
(1 client signal into 1 MPLS signal) or of the n:1 type (n client
signals multipelxed into 1 MPLS signal)
- a client layer signal is as such adapted to become an MPLS signal
before it is transported. Assume that MPLS OAM is available, such MPLS
OAM can be added to the signal to provide more extensive transport
monitoring capabilities to the signal transport. At this point,
end-to-end trail monitoring is established. 
- Traversing the MPLS layer network, the signal may pass through third
party subnetworks. Each of these subnetworks may need to monitor the
quality of service of the transport fo the signal through their network,
and these networks can now add a new level of MPLS OAM to the signal
(i.e. tandem connection monitoring). 
- Contrary to CBR techniques, MPLS doesn't have to steal overhead
bandwidht from the original signal. Instead it can simply add such OAM
to the signal. At the same time, it can add another MPLS header to the
signal and associate this with the new OAM that is added (improvement
over ATM's segment monitoring capability). This makes the signal
transport in one subnetwork domain realy independent of its transport in
previous domains (true independence is obtained).
- let me now focus on the multi-layer aspect of MPLS. If you multiplex
several MPLS signals into an MPLS aggregate signal, you have created
essentially a second MPLS layer network supporting the first MPLS layer
network. The trails in this second MPLS layer network support thus first
MPLS layer network links. 
- From a routing perspective links are static elements in the layer
network, and you can now operate the MPLS network as a bunch of
independent layer networks, with client/server relationships within the
MPLS network itself. On one technology you can now operate a number of
logical layers; e.g. an MPLS access layer, a MPLS metro layer and a MPLS
core layer. Each will have their specific characteristics (e.g. typical
bandwidth of the MPLS signal; small for access, medium for metro, large
for core).
- the nice thing here is that you can mix and match these logical MPLS
layer networks in equipment without the need to install different
fabrics. As each logical MPLS layer network can be run with its own
control plane instance, you will not run into scalability issues or
unwanted access/metro/core interactions. So, all the good stuff from CBR
networks without their restrictions. :-)

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

I have the feeling that we are converging. Let's see if the above notes
bring us even closer.

Up to so far. Regards, Maarten

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