The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Comments on draft-ip-optical-framework-00.txt
At 06:24 PM 3/27/00 -0500, Krishna Bala wrote: >Jagan, >Just to beat a dead horse .. the difference between the open model >and the overlay is just that the overlay model typically suggests that >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 >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. o-oh.. I wasn't suggesting that we do away with the term "overlay" at all.. But, your preference is noted ofcourse. Additionally - from my reading it did not seem that "overlay" implies static operation, or even a full connectivity between routers - N^2 as you mentioned. I was looking at some really old(?) IP/ATM debates and it seems like the term overlay/peer were used there as well and if I may, the debate was not much different either. In any case I do think that the parameters and the trade-offs are different than in the case of IP/ATM. I would like to see more discussion on that so that we can draw a more educated line between those two models in IP/Optical scenario. For example questions like - addressing, dynamic path establishment, router/router-like behavior of optical devices, L2-switch-like behavior of optical devices etc.. While the questions seem to be the same as when people were discussing how IP should be carried on ATM - will the answers be different in this case? One answer could be to let optics be stupid and simple and provide point to point connectivity - just the plain-old-transport-network? While we may be able to guarantee the behavior and correctly define the network in that case - it will probably not use the current technologies of configurability of wavelength paths and the ability to condense more and more high speed interfaces into a single box along with the switching intelligence that is required to make it powerful. -jagan. > >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 >> > > > Jagannath Shantigram Photonex Corporation
|
|