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@juniper.net]
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; iesg@ietf.org; ietf@ietf.org; ccamp@ops.ietf.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.