Re: Please Clarify Doubts regarding RGT & RNC

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Jeurgen,

A few more comments below, 
and a question for carriers, if any are listening.

Regards,
Ben

Heiles Juergen wrote:
> 
> Ben,
> 
> see my comments below.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [SMTP:Ben.Mack-Crane@tellabs.com]
> > Sent: Wednesday, March 28, 2001 5:36 PM
> > To:   Heiles Juergen
> > Cc:   sambasiva mantha; Vishal Sharma; 'manoj juneja'; ccamp@ops.ietf.org
> > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> >
> > Hello Jeurgen,
> >
> > I think we are in general agreement.  A few clarifications are included below.
> >
> > Regards,
> > Ben
> >
> > Heiles Juergen wrote:
> > >
> > > Ben,
> > >
> > > the characteristic information and the trail termination function are directly related as the
> > > characteristic infromation is generated/terminated by the trail termination function. So I don't
> > > see a need for additional trail termination information.
> >
> > Some trail termination information is not currently included in the signaling,
> > and probably should
> > be.  For example, the Trail Trace Identifier should be configured the same way
> > at source and sink,
> > but is not currently in the signaling spec (but certainly not as part of Signal
> > Type).
>         [Juergen Heiles]  Configuration of the trail trace is an open issue I agree.
> Draft-harrison-mpls-oam-00.txt proposes a trail trace (Connectivity verification CV OAM packets)
> for MPLS and suggest that the configuration of the trace is done via LSP signaling at LSP set-up.

In the MPLS (packet) case we have proposed that a standard convention be used to
create the TTSI (trail trace ID) from the Router ID of the ingress LSR and the local
ID for the LSP on that LSR.  We think this information is already in the signaling
messages (although the local ID should be 4 octets and only 2 are allocated in the
current signaling drafts).  If this is also acceptable for SONET/SDH trails, that
would solve the problem, but I don't know if that is true.  Carriers may have other
conventions already in use for assigning trail trace IDs and may not want to change.

Do you have any insight into this?  

Would any carriers like to comment?

> 
> > Also Payload
> > ID should be set properly, but this can be inferred (translated) from the GPID
> > that is signalled.
>         [Juergen Heiles]  The payload ID/Signal lable is not configurable as such, it is fixed
> defined by the adaptation function. What is configurable is the type of adaptation function itself
> if the network element provides this flexibility. As you noted the GPID is equivalent to the payload
> ID/signal label.
>         It should be noted that the LSP isn't necessarily used to setup a network connection between
> two trail terminations. I can also be used to setup sub-network connections. In the later case you
> don't know the payload ID and specific GPID.

Good point.  In fact, it may be that for many SNC cases the GPID will be set to 0 (unknown)
since the client layer may not be known (and is not relevant).

> 
> >  I don't know if there is other trail termination info that should be signalled
> > between the endpoints.
> > Do you have any thoughts on this?
>         [Juergen Heiles]  Tandem Connection Monitoring and setup of the TCM level might need some
> thoughts. Do we want to setup TCM automatically via LSP signaling at all?

It would be reasonable to support signaled setup of TCM, particularly in the case of SNCs.
For example, if the service is an SNC across a carrier's network, TCM may be required
to monitor the SLA for that SNC (the extent of the service provided by the carrier).

> 
> > >
> > > I agree with you that the RTG field combines different types of information. Contiguous concateantion
> > > is a characteristic information and should be coded into the signal type. As I mentioned before a
> > > STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> > > STS-3c-SPE into the signal type and RTG. A different coding for identical signals.
> >
> > We have gone back and forth on this topic.  Originally STS-3c was a concatenated
> > signal, then we
> > changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
> > and now it is
> > coded as a concatenated signal once more.  The current view is that it is
> > cleaner to code it
> > as a concatenated signal.  In either case I think we will have some way to code
> > the same signal
> > in two ways.  (If STS-3c is a separate signal type, it can still be coded as a
> > concatenated type
> > as well.)
>         [Juergen Heiles]  You might use a dedicated field for contiguous concatenation,
> but mixing it with bundling and virtual cocnatenation in one field has strange results. For example
> you cannot setup a virtual concatenation of N STS-3c with a common route, while you can setup virtual
> concatenation of N VC-4. I assume that virtual concatenation of STS-3c as it is equivalent to virtual
> concatenation of VC-4s.

We had some discussion of this among authors of GMPLS SONET/SDH signaling last week
and one possibility considered was that STS-3c groups could be identified by applying
the following convention:  If the signal type is OC-3 with no transparency (that is, no
line or section overhead included) AND some grouping type selected (e.g., virtual concatenation)
THEN one would assume the path structure was STS-3c.  This would also apply to other
standard contiguous concatenated rates (STS-12c, VC4-4c, etc.).  What do you think?

There is also a proposal to add another level of grouping by adding a multiplier field.
This would indicate that some number of grouped signal types is requested (e.g., a number
of arbitrary contiguous concatenated signals -- say 10xSTS-7c).  This is essentiually
a second level of grouping, with no type or routing constraint differentiation.


<snip>