[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Diversity of Routes Doubt
1 It difficult to understand the need for diversity and SVC-like
connections......diversity becomes an increasingly important factor as trail
holding time increases. So diversity is something important for
permanent/semi-permanent trails set under the management-plane or, in a
management proxy-type mode, by the control-plane (S-PVC-like).
2 All client layers inherit their connectivity from the duct
network....so a knowledge of the topology of the duct network is essential
to ensure diversity in a client network. However, no operator will own all
the layers 'to the duct' globally......so peering via exterior-NNIs will be
essential. This means that there will be no visibility of the duct topology
(nor allowed control of L1 resources) outside of a single domain. Hence,
the ability to calculate/force a strict source explicit route (or routes for
diversity) across inter-oprerator boundaries will in general not be
3 Item 2 above will impact other issues related to resilience. For
example, even assuming one believes pre-emption will yield any
tangible/deterministic benefit within a single domain it is hard to see how
this concept could be extended across exterior-NNIs.
> -----Original Message-----
> From: Fong Liaw [mailto:firstname.lastname@example.org]
> Sent: 23 June 2001 01:25
> To: 'manoj juneja'; email@example.com
> Subject: RE: Diversity of Routes Doubt
> I am not sure CCAMP is the right email list to discuss
> OIF UNI specific attributes/object. I will respond here,
> but we can take it off-line or to firstname.lastname@example.org
> if needed.
> > -----Original Message-----
> > From: manoj juneja [mailto:email@example.com]
> > Sent: Friday, June 22, 2001 4:43 PM
> > To: firstname.lastname@example.org
> > Subject: Diversity of Routes Doubt
> > Hi All,
> > The OIF-UNI draft contains diversity sub-object (part of
> > Generalized UNI Attribute object). There is no such object in GMPLS
> > drafts. In a typical scenario, where one O-UNI request has to be
> > converted/translated/mapped to one GMPLS (NNI) request, how to
> > interpret/translate the diversity TLV/object ?
> The UNI diversity subobject includes a connection identifier and
> the diversity requirement, e.g. node, link, etc. The first
> switch (ONE) should use the connection identifier to find out
> the path (links and nodes) of the identified connection and
> then use it to compute ERO that would diverse from the nodes,
> links, or SRLG.
> > Is it the responsibility of network manager to offline
> calculate the
> > ERO (and pass in the path message from the edge/ingress ONE) which
> > statisfies the diverstiy of the route desired by the client
> I don't think this can be done offline, since it changes
> according to which connection you want to diversify from.
> But it can be done by either centralized or distributed
> computation, and precomputation might be possible.
> > equipment ? Does this mean the usage of strict routes in ERO ?
> > Should we be having the diversity object in GMPLS drafts also ?
> Use of strict route in ERO is probably the simplest and common
> approach in single domain. Using loose route ERO is possible
> but could be more complicate. This may come into GMPLS/OIF NNI
> if diversity across multiple domain becomes a requirement.
> We don't have this requirement yet, so there is no need to introduce
> it into GMPLS yet.
> > Please clarify my doubt.
> > Regards,
> > manoj.
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com