Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt

[Yangguang Xu <xuyg@lucent.com>]

Ayan,


> The TSpec, as I understand it, carries only bandwidth information
> for some label types. 

I think it carries more than that. It carries the signal type, and a signal type
specifies the bandwidth information implicitly. More important, a signal type
specifies what type of circuit connection you want to switch, e.g. a SONET LSP
or a SDH LSP, and other details.

Please refer to the SONET/SDH draft.
 
> As a result, we do need the encoding type
> and the switching capability field for a mutli-service platform
> to allocate resources and/or validate a particular connection
> encoding type. I think we agree until here.
> 

My point is that we don't need switching capability field. The previous version
works fine. Again, the encoding type + signal type can identify what kind of
connection you want to set up. No further information is needed.

For example, if a NE receives a request with encoding type = SONET, signal type
= STS-1. Even the NE has dual switching fabrics, say one STS-1 SF and one packet
SF, the NE knows exactly what to do.

> For example, if a TE link has both SDH and SONET "ports" bundled
> within it (a list of interface switching capability descriptors
> allow for this), it has to be notified that this request is for a
> SONET port. This is not negotiation, it is a request to get a resource
> for a port that can carry a particular type of connection. The TE-link
> should not at this time give you a resource label for a SDH port when
> you request for a SONET port. As a result, this field also needs to be
> carried while signaling setup request is made.
> 

First, the example is a little bit weird to me (probably because of my limited
experience). If the NE is a SONET/SDH gateway, SONET and SDH ports should be
separate to east bound and west bound. They wouldn't mix. However, let take your
example. 

First, if you have both SDH and SONET "ports", they should be bundled as two
different logical links. Your routing algorithm should specify which bundle to
use. Then at each node, the local intelligence chooses the a component interface
ID from the bundle ID in the ERO. When the next node receives the request with
the component interface ID, it should choose the egress port with the same
physical attributes. So you don't need switching capacity field, neither the
"port" encoding type.

If they are not bundled separately, from the signal type, a NE knows the request
is for a SONET STS-1 (for example), it chooses the SONET port, not the SDH port.
The key is that the encoding type is the requested LSP encoding type, not the
"port" encoding type.

In either case, a NE doesn't need to worry about the port encoding type in the
signaling other than the LSP encoding type + signal type.

Regards,

Yangguang