[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: trail trace (was: Please Clarify Doubts regarding RGT & RNC)

Ben,

I have split my response into e-mails with different subjects.
This one is on trail trace.

Regards

Juergen


> -----Original Message-----
> From:	Ben Mack-Crane [SMTP:Ben.Mack-Crane@tellabs.com]
> Sent:	Thursday, March 29, 2001 6:26 PM
> To:	Heiles Juergen
> Cc:	sambasiva mantha; Vishal Sharma; 'manoj juneja'; ccamp@ops.ietf.org
> Subject:	Re: Please Clarify Doubts regarding RGT & RNC
> 
	<snip>>
> > > > 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?  
	[Juergen Heiles]  In SDH we have a 16 or optinal 64 byte trace. The 16 byte trace is the soruce address which normally cnsits of country code, operator code and a unique number within the operator domain. For the OTN we use a 64 byte trace.  It consist of a 16 byte source and 16 byte destination address (country code + operator code + unique number). The remianing 32 bytes are availablefor operator specific purposes. 

> Would any carriers like to comment?
> 
> 
	<snip>