[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Sonet extensions
Hi Greg.....you might find re-visting the 'Freeland' draft BT submitted to
the 12/00 San Diego mtg helpful when reviewing the OTN inter-domain routing
work you mentioned below.
Some other observations on this discussion are:
- there is vertical layering between technologies and horizontal
partitioning within/per (single technology) layer networks. The latter is a
very important aspect, since it is usually associated with commercial
management domains (and can also involve different vendor interworking). So
we can have a single management domain at technology/layer N served by
several different disjoint/tandemmed commercial domains at layer
N-1......clearly these relationships can recurse.
- as we get closer to the duct layer network (yes it is a real layer
network) the trail holding times must increase for stability.....so the need
for SVC-like services decreases as we move to the duct.
- I find it hard to understand how any operator will be able to make a
valid business case for large BW L1 SVC services; SVCs need a 'law of large
numbers' environment such that any single instance of a demand is almost
unoticable on the network....so as we get closer to the duct:- S-PVCs yes,
SVCs no; so we really don't need UNIs, but we do need NNIs (and different
interior and exterior NNIs);
- unless one has total control of all layer networks to the duct then
one cannot even contemplate an accurate view of resources (including
resilience design.....since disjoint connectivity in all client layers is
defined/inherited from the duct layer). The immediate corrolary of this is
that if any operator wishes to serve a global customer base then:
(i) that operator must accept peering with other operators and
virtualisation of server layers......and note that in such a relationship
each peering operator will demand isolation of what is/is-not allowed to be
advertised/controlled across that (exterior) NNI....which usually means this
reduces to simple reachability; OR
(ii) that operator must build out (to the duct) globally.
Guess which model has more chance of obtaining acceptance with operators
(especially their finance people!)?
- SDH will be a client of the OTN......and there will be several
client layers of SDH. These layer networks are commercially important to
operators and cannot be discounted. It is also an interesting exercise to
find out just what a sizeable business peer (or as Maarten calls them
'native') managed BW demands are on the L1 networks.....probably bigger than
most non-operators realise.
- we (I am speaking as BT here) can set-up L1 trails in SDH very fast
now using management tools....introducing a control-plane is not going to
speed up the process by any significant degree unless it can also dig
trenches, lay ducts, install equipment and do order processing, link to
billing (and all our other OSS), etc!
As I said, the Freeland draft from BT has additional pointers as to what we,
as at least one operator, need for the L1 networks if a control-plane is
introduced. But as to the choice of the the most *appropriate*
control-plane facets, that is a different question ;-). But one thing is
for sure......there will have to be hard decoupling between client layers
and the SDH/OTN server layers. This is not really a technical issue for
argument, it is commercial necessity.
regards, Neil
> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: 11 June 2001 17:14
> To: 'Maarten Vissers'; Diego Caviglia
> Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron;
> ccamp@ops.ietf.org
> Subject: RE: GMPLS Sonet extensions
>
>
> 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
> > > >
>