Kireeti, I know I've really taken my time (days) to get text to you. The
intent is to describe the motivation for layer information and not delve
into what attributes might be added in the future (e.g., max contiguous
connections on a link) or that may be layer specific. In fact, attributes
could be created that address several factors at once. The text could go
into section 3 somewhere of <draft-ietf-ccamp-gmpls-routing-05.txt>.
----------------------
Representing TE Link Capabilities
In generalizing TE links to include traditional transport (in the optical
sense) facilities, there are additional factors that influence what
information is needed about the TE link. These arise from existing
transport layer architecture (e.g., ITU-T Recommendations G.805 and G.806)
and associated layer services. Some of these factors are:
1. The need for LSPs at a specific adaptation, not just a particular
bandwidth. Clients of optical networks obtain connection services for
specific adaptations. For example a VC-3 circuit. This not only implies a
particular bandwidth, but how the payload is structured. Thus the VC-3
client would not be satisfied with any LSP that offered other than 48.384
Mbit/s and with the expected structure.
2. Enable path computation to find a layer specific path. Following
from the first factor, path computation must be able to find a route that
would give a connection at a specific adaptation. For example a VC-3
connection where all hops maintain the VC-3 characteristic information.
This is conceptually identical to the situation where links in a routing
database have "colour" attributes and a path of a particular "colour" is
needed.
3. Distinguishing variable adaptation. A resource between two OXCs
(specifically a G.805 trail) can sometimes support different adaptations at
the same time. An example of this is described in section 4.4.8. In this
situation, the fact that two adaptations are supported on the same trail is
important because the two layers are dependent. When a label (channel) is
used at a particular layer, it has the effect of modifying the available
labels in other layers supported on the same link. It is important to thus
be able to reflect the layer relationship in routing.
4. Interlayer relationships. In L2 MPLS, it is possible to change
encapsulations (label type) throughout an LSP without much regard for the
bandwidth supported by the link at each hop. This is a result of the
relative ease of adaptations between packet formats. That is, at each LSP
hop the frame can be decapsulated and the data encapsulated in another L2
format. In contrast, transport layers have much more restrictive
adaptations than in packet layer and are structured in an adaptation
hierarchy. This lack of flexibility compared to packet layers requires
explicit indication of layer relationships.
5. Inheritable attributes. When a whole multiplexing hierarchy is
supported by a TE link, a lower layer attribute may be applicable to the
upper layers. Protection attributes are a good example of this. If an
OC-192 link is 1+1 protected (a duplicate OC-192 exists for protection),
then an OC-3c within that OC-192 (a higher layer) would inherit the same
protection property. Recognizing this type of attribute is thus important
in TE links.
6. Extensibility of layers. In addition to the existing defined
transport layers, new layers and adaptation relationships could come into
existence in the future. Keeping this in mind for TE-link attributes is
important.
7. Heterogeneous networks whose OXCs do not all support the same set of
layers. In a GMPLS network, not all transport layer network elements are
expected to support the same layers. For example, there may be switches
capable of only VC-11, VC-12, and VC-3, where as there may be others that
can only support VC-3 and VC-4. Even though a network element cannot
support a specific layer, it should be able to know if a network element
elsewhere in the network can support an adaptation that would enable that
unsupported layer to be used. For example, a VC-11 switch could use a VC-3
capable switch if it knew that a VC-11 path could be constructed over a VC-3
link connection.
8. Organization of links. Within a given layer, resources between two
OXCs may be organized as several links. Attributes may be associated with a
set of these links (bundles).
From the factors presented above, development of layer specific GMPLS
routing drafts should use the following principles for TE-link attributes.
1. The attributes in a given layer are separated from attributes in
another layer.
2. Support of inter-layer attributes (e.g., adaptation relationships).
Between a client and server layer, a general mechanism for describing the
layer relationship exists. For example "4 client links of type X can be
supported by this server layer link". Another example is being able to
identify when two layers share a common server layer.
3. Support inheritable attributes. Attributes which can be inherited
should be identified.
4. Attributes should be represented in routing such that future layers
can be accommodated. This is much like the notion of the generalized label.
5. Attribute scope should be explicit. For example, whether the
attribute applies to a set of links at the same layer.
-----Original Message-----
From: Kireeti Kompella [mailto:kireeti(_at_)juniper(_dot_)net]
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
ccamp(_at_)ops(_dot_)ietf(_dot_)org
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS
vto Proposed Standard
Hi Stephen,
On Mon, 3 Mar 2003, Stephen Shew wrote:
I don't know if the pun was intended, but I do like Kireeti's comment
about "bring them to light".
You're laser sharp, Stephen! :-)
Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-)
After the discussions we've had, I wouldn't dare not comply.
There is, I think, some commonality in the comments and the reply in
that the intent is to generalize the extensions needed for routing to
accomodate non-PSC resources. I agree with the first 4 points that
Jonathan made in that I think layer information must be included in
routing so that important functions can be performed.
Okay. Can you provide text?
I believe that the use of one or two bandwidth
values was motivated by the desire to use a "lowest common
denominator" attribute to generalize on path computation and avoid
extensive details of links. Unfortunately, this can obscure variable
adaptation on a link and the ability to determine a path at a
particular adaptation (e.g., VC-3).
You're right on both counts (about LCD, and about obscuring info). The
thinking was (a) let's see how far we can get with just the LCD;
(b) as we learn more, we can incorporate them, ideally in the SDH routing
doc.
Thoughts?
Kireeti.