[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Sonet extensions
Diego,
Comments inline.
-Vishal
On Tuesday, June 12, 2001 2:51 AM, Diego Caviglia
[SMTP:Diego.Caviglia@marconi.com] 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
Exactly right.
> 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?
Good question. I believe it is this aggregation that Greg was alluding to
in his email, but we'll wait to hear what he has to say.
> 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.
Exactly the point! This is indeed what needs to be looked at carefully.
Of course, this does not mean abandoning the layered network approach
(Maarten would certainly think that will collapse the global transport network
:-)).
But... it does mean a thorough examination of the available protocols,
in the light of what is needed, to see if they can be made to fit the bill, and
yet be made scalable, or if something new entirely might be needed.
> 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.
Technically, in a layered network under a common control plane this could
certainly happen. However, when a request crosses the "layers" in a layered
network in this manner, I believe it would have to have some interaction with
the EMS/NMS or a policy engine somewhere that would need to determine
what kind of HOVC or lambda trail needs to be setup to accommodate this
(and possibly future) requests.
> 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
> > > > >
> << File: mvissers.vcf >>