The MPLS WG Archive

[Jonathan Lang <jplang@lux.chromisys.com>]

The Architecture Working Group of the OIF is discussing both the Peer model
and the Overlay model.

Regards,
Jonathan

-----Original Message-----
From: Krishna Bala [mailto:kbala@tellium.com]
Sent: Tuesday, March 28, 2000 11:27 PM
To: James V. Luciani; Jagan Shantigram; Jonathan Lang; curtis@avici.com
Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com
Subject: RE: Comments on draft-ip-optical-framework-00.txt 


Jim,
Hmm!

The OIF is using the terms
1) Peer
2) Open

So, if possible ... so as to avoid creating yet another term for
the same thing (X in this case) I suggest we call it "open".

Krishna

> -----Original Message-----
> From: James V. Luciani [mailto:jluciani@tollbridgetech.com]
> Sent: Monday, March 27, 2000 6:42 PM
> To: Krishna Bala; Jagan Shantigram; Jonathan Lang; curtis@avici.com
> Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com
> Subject: Re: Comments on draft-ip-optical-framework-00.txt
>
>
>
> > Just to beat a dead horse .. the difference between the open model
> > and the overlay is just that the overlay model typically suggests that
>
> That depends... see below.
>
> > there would be N^2 connectivity (i.e., every router, for instance, is
> > statically connected to every other). In any case, the open model allows
>
> While there may indeed be some misunderstanding as to the meaning of the
> "overlay model" (not to mention the meaning of the other models :-)), the
> traditional definition of overlay is not one of static operation.
>  NHRP and
> MPOA, for example, are overlay in my book (and most folks that I know).
> They most certainly imply non-static connections by defintion
> (i.e., use of
> SVCs).  This having been said, I believe that we can do one of two things
> here.  One, keep the current terms and potentially risk an ad nauseum
> inspection of the meaning of these terms; or two, come up with a
> term which
> is satisfactory to all.  In the second case we would have models:
> 1) X
> 2) Peer
> where X is the PC term for what we want to get at.  So my opine is that
> X="augmented routing model"/ARM model.
>
> Do I hear a hmmmm???
> --Jim
>
> > for fully dynamic operation. The overlay model suggests static operation
> of
> > the optical layer.
> >
> > As I see it there are only two architectures that are worth considering:
> > 1. Peer
> > 2. Open
> >
> > I agree with you that there is no need to add the "overlay" model to
> > this list. The open model covers the static and the dynamic cases.
> >
> > Krishna
> >
> > > -----Original Message-----
> > > From: Jagan Shantigram [mailto:jagan@photonex.com]
> > > Sent: Monday, March 27, 2000 10:14 AM
> > > To: Krishna Bala; Jonathan Lang; curtis@avici.com
> > > Cc: Khaled Elsayed; mpls@UU.NET;
> ip-optical@lists.research.bell-labs.com
> > > Subject: RE: Comments on draft-ip-optical-framework-00.txt
> > >
> > >
> > > At 05:04 PM 3/24/00 -0500, Krishna Bala wrote:
> > > >Jonathan,
> > > >Point 1: Let me clarify the "open model".
> > > >
> > > >Open refers to the fact that this model supports the
> interconnection of
> > > >several types of clients to an optical network (server layer).
> > > >Examples of Clients:
> > > >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services"
> > > >
> > > >The open model also allows the interconnection of other
> Optical Network
> > > >Elements to
> > > >each other.
> > > >Examples of other Network Elements:
> > > >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC,
> Wavelength
> > > >Interchanging XC
> > > >
> > > >In general, since it offers the capability to support ALL
> > > services (not just
> > > >IP)
> > > >it is an Open Model.
> > >
> > > Krishna,
> > >
> > > It seems like the above just described what people understand
> > > by the overlay model. In this model the optical layer presents
> > > itself as a layer that can provide a bunch of services to the
> > > upper data/IP layer. These services could include point
> > > to point clear channel, 1+1 protection, negotiable bandwidth
> > > etc.. (just to give examples). How the optical layer
> > > achieves these services is yet to be determined - which as you
> > > mention will require standardized interfaces between the various
> > > optical components and as well as a standardized API for these
> > > services to be requested.
> > >
> > > My question is what are these services that would be useful
> > > for the optical layer to provide and what are the tasks that
> > > have to be taken up to enable it?
> > >
> > > In any case it seems risky to take up a model that requires
> > > too much cooperation between the various layers - since that
> > > will mean that there will be inter-dependence in the development
> > > of that technology. Ofcourse there are others who have more
> > > experience on questions like this.
> > >
> > >
> > > >
> > > >Point 2: Overlay Model vs. Open
> > > >
> > > >The connotation that goes typically with the Overlay model
> is that the
> > > >optical
> > > >layer is quasi static and might require N^2 connectivity at the
> IP/client
> > > >layer.
> > >
> > > Am afraid I missed the point here.
> > >
> > > thanks,
> > > -jagan.
> > >
> > >
> > > >Hence, I prefer to distinguish the open model from overlay.
> > > >Krishna Bala
> > > >
> > > >> -----Original Message-----
> > > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> Jonathan
> > > >> Lang
> > > >> Sent: Thursday, March 23, 2000 4:55 PM
> > > >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram
> > > >> Cc: Khaled Elsayed; mpls@UU.NET;
> > > ip-optical@lists.research.bell-labs.com
> > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt
> > > >>
> > > >>
> > > >> Krishna,
> > > >>   The Open model seems quite "Closed" to me - the very nature of
> clouds
> > > >> implies information hiding in my mind.  What is exactly meant by
> open?
> > > >> Also, I'm not sure I agree with your definition of overlay, as
> > > many people
> > > >> allow the overlay model to encompass both your (2) and (3).
> > > >> Furthermore, I
> > > >> don't think the Peer Model implies OXCs are "agile but fat &
> > > >> dumb" since as
> > > >> they are "peers", this would also imply routers are "agile but
> > > fat & dumb"
> > > >> as well - and at some point, someone needs to have
> > > intelligence.  I would
> > > >> suggest that the Peer model allows both routers and OXCs to
> > > interoperate
> > > >> intelligently.
> > > >>
> > > >> Regards,
> > > >> Jonathan
> > > >>
> > > >> -----Original Message-----
> > > >> From: Krishna Bala [mailto:kbala@tellium.com]
> > > >> Sent: Thursday, March 23, 2000 11:59 AM
> > > >> To: curtis@avici.com; Jagan Shantigram
> > > >> Cc: Khaled Elsayed; mpls@UU.NET;
> > > ip-optical@lists.research.bell-labs.com
> > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt
> > > >>
> > > >>
> > > >> Jagan,
> > > >> There are several architectural models for IP over Optical
> > > Networks that
> > > >> are emerging:
> > > >>
> > > >> 1. Peer Model
> > > >> In this model the IP router is entirely aware of the details on the
> > > >> underlying
> > > >> optical network (topology information, wavelength and port
> > > usage and lamda
> > > >> assignment).
> > > >> It is able to control and manage entire end to end paths. In this
> > > >> model the
> > > >> OXC is "agile but fat & dumb".
> > > >> 2. Overlay Model
> > > >> The optical layer is "fat & dumb". The lamda connections
> between the
> IP
> > > >> routers behave as if they were dedicated fibers between them. The
> > > >> IP routes
> > > >> provision logical optical circuits over a fixed or at best a
> > > quasi-fixed
> > > >> optical
> > > >> layer.
> > > >> 3. Open Model
> > > >> In this scenario the optical layer comprises of several
> "vendor/network
> > > >> operator clouds"
> > > >> that have well defined interfaces. For example, an Optical UNI
> > > can be used
> > > >> to
> > > >> interconnect the IP router to the OXC and the Optical NNI can
> > > be used to
> > > >> connect
> > > >> two optical network domains together. Here the optical layer is
> > > >> "fat, smart
> > > >> and agile".
> > > >>
> > > >> It is unclear at this time which of these models will prevail.
> > > >>
> > > >> Krishna Bala
> > > >> Tellium
> > > >>
> > > >>
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> Curtis
> > > >> > Villamizar
> > > >> > Sent: Thursday, March 23, 2000 1:55 PM
> > > >> > To: Jagan Shantigram
> > > >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET;
> > > >> > ip-optical@lists.research.bell-labs.com
> > > >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt
> > > >> >
> > > >> >
> > > >> >
> > > >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan
> > > >> > Shantigram wr
> > > >> > ites:
> > > >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote:
> > > >> > > >
> > > >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled
> Elsayed writes:
> > > >> > > >>
> > > >> > > >>
> > > >> > > >> Hello Jagan,
> > > >> > > >>
> > > >> > > >> > When we do not have lambda conversion however, this
> > > >> problem cannot
> > > >> > > >> > be solved optimally.. it is akin to the graph coloring
> > > >> > > >> > problem - which ofcourse has heuristics that can get us to
> > > >> > > >> > a factor (?) of the optimal solution. So, connections may
> > > >> > > >> > be blocked even though there is capacity on the fiber to
> > > >> > > >> > support it, just because the wavelength is
> already used up.
> > > >> > > >> >
> > > >> > > >>
> > > >> > > >> Connections can be blocked when?? At service
> > > provisioning time or
> > > >> > > >> at the time the connection is requested?? My point is a
> > > >> > > >> connection of 2.48 Gbps is not likely to be a
> random event or
> an
> > > >> > > >> ATM-like SVC. If a customer would require such huge
> > > bandwidth, it
> > > >> > > >> would need that BW to go through or it would better look for
> > > >> > > >> another carrier that will provide a TDM/leased line?? Of
> course
> > > >> > > >> wavelength conversion can help build a better-utilized
> network,
> > > >> > > >> no question about that.
> > > >> > > >>
> > > >> > > >> Khaled
> > > >> > > >
> > > >> > > >
> > > >> > > >The exception to the rule that "a connection of 2.48
> Gbps is not
> > > >> > > >likely to be a random event" is where a very major event,
> > > possilble
> > > >> > > >external to one's own network results in a shift in
> > > traffic patterns
> > > >> > > >that is significant enough to require that additional
> > > >> lambdas be added
> > > >> > > >to existing paths.
> > > >> > > >
> > > >> > > >The real world example in the ISP world is a failure of a
> peering
> > > >> > > >point of some sort, a provider interconnect, a NAP or NAP
> > > >> connectivity
> > > >> > > >of some party.  Since all major ISPs are connected to
> > > each other at
> > > >> > > >more than one geographically diverse peering point, the
> > > traffic will
> > > >> > > >still flow, but the path will have changed.
> > > >> > > >
> > > >> > > >This may mean that a path that previously required 3 lambdas
> (for
> > > >> > > >example), now requires 4 lambdas.  There are at least
> 3 ways to
> > > >> > > >accommodate this requirement:
> > > >> > > >
> > > >> > > >  1.  An external management system adds a lambda to both
> > > the routers
> > > >> > > >      at either end and the optical switches
> > > (demonstrated at OFC).
> > > >> > > >
> > > >> > > >  2.  The router signals the requirement/desire for an
> additional
> > > >> > > >      lambda to the adjacent optical switch which sets up a
> path.
> > > >> > > >      This is the overlay model.  It can be trivially
> > > >> implemented with
> > > >> > > >      MPLS by having the router send a loose source hop in the
> ERO
> > > >> > > >      allowing the switch to create the path or reject
> > > the request.
> > > >> > >
> > > >> > > Curtis,
> > > >> > >
> > > >> > > Am trying to understand the model here. Does the overlay model
> > > >> > > as you put above imply that the optical devices need to be
> > > >> mini-routers
> > > >> > > in their own right? They have to be able to set up
> > > end-to-end optical
> > > >> > > paths.. perhaps some kind of binding between the end-host
> > > IP address
> > > >> > > and an addressing scheme for Optical devices.. ala ATM?
> > > >> > > What does the overlay model entail?
> > > >> >
> > > >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP
> (or
> > > >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC.
> > > >> >
> > > >> > Alternately, the lambdas can be set statically and the
> edge router
> > > >> > simple advertises a Lambda-Switch Capable link ala
> > > >> > draft-kompella-mpls-optical-00.txt (if I understand their intent
> wrt
> > > >> > accommodating the overlay model).
> > > >> >
> > > >> > I don't think draft-kompella-mpls-optical-00.txt has all the
> details
> > > >> > sufficiently ironed out for the case where the optical switch
> > > >> > advertises the availability of an optical link.  If it does, then
> the
> > > >> > details ar just not clear to me.  (Could be my careless reading).
> > > >> >
> > > >> > > >  3.  The router has enough information about the
> > > characteristics of
> > > >> > > >      the optical devices to compute the path and so it does
> > > >> so.  This
> > > >> > > >      is the peer model.
> > > >> > > >
> > > >> > >
> > > >> > > What does this model need.. a protocol for exchanging
> information
> > > >> > > between the router and the optical device?
> > > >> >
> > > >> > It needs a means to communicate OOB wrt the primary lightpath.
> That
> > > >> > means would again be running the IGP and RSVP.  Based on reading
> the
> > > >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear
> on how the
> > > >> > optical switch exchanges this information OOB although I
> > > would imagine
> > > >> > that it would be quite easy to maintian another
> interface (perhaps
> > > >> > even an electrical, though gig-E would do fine) between the
> > > router and
> > > >> > optical device in which the optical device advertises the optical
> > > >> > links.  The router on either end of an optical link, seeing or
> having
> > > >> > set up a Packet-Switch Capable link would then have to
> bring up an
> > > >> > RSVP adjacency over it, though I think it would not need an IGP
> > > >> > adjacency.  (I'm not clear on this last point.)
> > > >> >
> > > >> > The availability of certain types of links
> (Packet-Switch Capable,
> > > >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in
> > > >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP.
> I'm
> > > >> > not clear on whether the adjacent LSR should advertise a
> Forwarding
> > > >> > Adjacency PSC after RSVP comes up over a set of optical links (it
> > > >> > seems to be the intent) but maybe the authors can clarify the
> usage.
> > > >> >
> > > >> > The ongoing discussion and the topic of the (way too numerous)
> > > >> > framework documents floating around has been what additional
> > > >> > information would be needed in order to provide adequate
> constraints
> > > >> > to set up optical paths, a particularly difficult problem for
> > > >> > transparent paths.
> > > >> >
> > > >> > > -jagan.
> > > >> > >
> > > >> > > >The way this might manifest itself is LSPs that might
> > > take an optical
> > > >> > > >path from A to C are going from A to B to C because A to C
> > > >> lambdas are
> > > >> > > >too full.  If so, then A could in principle request an
> additional
> > > >> > > >lambda, but in practice the means to signal this has not
> > > >> been defined.
> > > >> > > >
> > > >> > > >Curtis
> > > >> > >
> > > >> > > Jagannath Shantigram
> > > >> > > Photonex Corporation
> > > >> >
> > > >> > btw- I exchanged some private email with one of the authors of
> > > >> > draft-kompella-mpls-optical.txt and owe them some
> detailed comments
> > > >> > (appologies to them for the delay, busy).  After some brief
> > > discussion
> > > >> > and after a second reading, the intent seems a lot more
> clear.  The
> > > >> > usage material is at the end so when reading the document from
> front
> > > >> > to back the intent is not clear until the end and then a second
> > > >> > reading is required.
> > > >> >
> > > >> > Curtis
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> > > Jagannath Shantigram
> > > Photonex Corporation
> > >
>