RE: J0/J1 encoding issues

[[e-mail]]

Thanks Maarten,

It's also worth saying that the principle Maarten is stating here (ie an
ability to uniquely identify a data-plane trail termination source) should
be available to be used in *all* technologies in all 3 network classes, be
they cnls, co pkt-sw or co cct-sw.
Note - In cnls this is a default given anyway, ie each/every pkt contains a
unique (to network it is in)  source identifier.

And this is precisely why Y.1711 specifies a TTSI (Trail Termination Source
Identifier) in the CV (Connectivity Verification) pkt.  For exmaple, this
allows fast squelching of traffic if an LSP misconnection occurs.....though
this not the only automatic defect detection/handling aspect that has to be
considered.

regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]]
> Sent: 05 December 2002 10:01
> To: John Drake
> Cc: 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> 
> John,
> 
> Here is a copy of the text of section 3/G.831 which defines 
> the Access Point
> Identifier that is transmitted in the Trail Trace Identifiers 
> (J0, J1, J2 in
> SDH):
> 
> ================ section 3/G.831 =====================================
> 
> 3	SDH access point identification
> 
> An essential requirement for successful management of SDH 
> networks incorporating
> features such as point-to-point and point-to-multipoint paths 
> is a unique means
> of identifying significant points in the network, e.g. access 
> points. The
> features of Access Point Identifiers (APIs) are:
> 
> - each access point identifier must be globally unique in its 
> layer network;
> - where it may be expected that the access point may be 
> required for path
>   set-up across an inter-operator boundary, the access point 
> identifier
>   must be available to other network operators;
> - the access point identifier should not change while the access point
>   remains in existence;
> - the access point identifier should be able to identify the country
>   and network operator which is responsible for routing to 
> and from the
>   access point;
> - the set of all access point identifiers belonging to a single
>   administrative layer network should form a single access point
>   identification scheme;
> - the scheme of access point identifiers for each administrative
>   layer network can be independent from the scheme in any other
>   administrative layer network.
> 
> It is recommended that the VC-11, VC-12, VC-2, VC-2-xc, VC-3, 
> VC-4 and VC-4-xc
> should each have the access point identification scheme bases 
> on a tree-like
> format to aid routing control search algorithms. The access 
> point identifier
> should be globally unambiguous.
> 
> The API shall begin with either the country code as defined 
> in ITU-T E.164 (one,
> two or three numeric characters) or, the three alphabetic 
> character country code
> as defined in ISO 3166.
> 
> The remainder of the API characters that follow the country 
> code shall be a
> matter for the organization to whom the country code has been 
> assigned, provided
> that uniqueness is guaranteed. These characters may be any 
> alphanumeric
> characters as defined in ITU-T T.50 (International Reference 
> Version - 7-bit
> coded character set for information interchange).
> 
> The alphanumeric character set consists of the characters "a" 
> to "z", "A" to
> "Z", and "0" to "9".
> In the case where the API uses less than fifteen characters, 
> the API will be
> padded (extended) with the T.50 "NUL" character to get a 
> fifteen byte character
> string.
>  
> For interworking with equipment developed prior to this version of the
> Recommendation that may use the T.50 space as a padding 
> character, new equipment
> should be able to generate T.50 "SPACE" padding characters as 
> an option.
> 
> A similar access and test point identification scheme is 
> required for the
> section layer to support point-to-point and 
> point-to-multipoint paths and wide
> area multiplexors as used in satellite subnetworks.
> 
> The byte allocations for the transmission of the access point 
> identifier at the
> section layer, higher?order path layer and lower-order path 
> layer are given in
> ITU-T G.707.
> 
> ================= end of section 3/G.831 =============================
> 
> Furthermore, there is the ANSI specification in "Structure 
> and Representation of
> Trace
> Message Formats for the North American Telecommunications 
> System T1.269-2000". 
> This standard specifies the National Segment portion of the API.
> 
> 
> As you can see G.831 restricts the character set to the 
> alfanumeric symbols
> a..z, A..Z and 0..9 with NUL (or SPACE) padding at the end.
> 
> Regards,
> 
> Maarten
> PS. Older SDH equipment developed before the first version of 
> G.831 (08/96) was
> often less restrictive in the supported character set, and 
> allowed other
> printable and non-printable characters. This caused a lot of 
> headaches when
> trying to discover why there was a Trace Identfier Mismatch 
> (TIM) alarm; the
> Expected Trace Identifier and the Received Trace Identifier 
> looked the same on
> the GUI. Only when the GUI supported a HEX presentation mode, 
> it was possible to
> discover the non-printable characters that were causing the mismatch.
> 
> Regards,
> 
> Maarten
> 
> John Drake wrote:
> > 
> > Jonathan S,
> > 
> > Okay, now you've really confused me.
> > 
> > In this e-mail, you seem to be saying that any T.50 
> character is valid in
> > J0/J1/J2.  However, in your earlier e-mail, which is 
> included way down at
> > the bottom of this e-mail, you say "The requirements for 
> J0/J1/J2 (found
> > in G.707) state the trace message payload must utilize the printable
> > characters
> > defined in T.50".
> > 
> > Which is the real requirement?
> > 
> > If it is the former, then there is no issue with
> > draft-lang-ccamp-lmp-bootstrap.
> > I.e., T.50 defines all possible 7 bit values and
> > draft-lang-ccamp-lmp-bootstrap
> > specifies that 7 bits of information are to be carried in 
> each octet, so by
> > definition every possible seven bit value is a valid T.50 character.
> > 
> > If it is the latter, then it doesn't sound as though the 
> latest draft
> > G.7714.1
> > is any more conformant than draft-lang-ccamp-lmp-bootstrap is.
> > 
> > Thanks,
> > 
> > John
> > 
> > 
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[e-mail]]
> > Sent: Tuesday, November 26, 2002 8:49 AM
> > To: John Drake
> > Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> > 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> > 
> > John,
> > 
> > There are a number of T.50 characters that are non-E.164 and
> > non-alphabetic.  The use of a non-E.164 and non-alphabetic 
> character in
> > the format defined by draft G.7714.1 is to provide backward
> > compatability with the country-specific and 
> carrier-specific encodings
> > described in G.831.
> > 
> > Jonathan Sadler
> > 
> > John Drake wrote:
> > >
> > > Rajender,
> > >
> > > Why don't you send a pointer to the draft, so that any 
> interested party
> > can
> > > take a look at it and decide for themselves?
> > >
> > > As I understand it, the  version presented at the Experts 
> Meeting in
> > Ottawa
> > > did not comply with T.50 requirements, and it is only the 
> newest draft
> > > version that attempts to address the T.50 requirements.  
> It does so by
> > > re-defining current Jx processing with a new format that 
> "uses a non-E.164
> > > and non-alphabetic character in the first byte of the message".
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Razdan, Rajender [mailto:[e-mail]]
> > > Sent: Monday, November 25, 2002 8:55 AM
> > > To: John Drake; [e-mail]
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > John,
> > >
> > >     I don't subscribe to the ccamp mailing list, and so 
> haven't had a
> > chance
> > > to comment on the LMP drafts till now. The discussion on 
> J0/J1 issues was
> > > forwarded to me by Jonathan Sadler. As the editor of 
> Draft G.7714.1, I was
> > > quite distressed to read about your understanding that 
> none of the work
> > > aimed
> > > at G.7714.1 is compatible with the T.50 requirement. I 
> don't know how you
> > > got
> > > that absolutely wrong impression. In fact, compatibility 
> with the T.50
> > > requirement, as dictated by ITU Rec. G.707, has been the 
> most important
> > > consideration for us in our defining J0/J1/J2 discovery 
> mechanisms. The
> > > current
> > > draft of G.7714.1 clearly states this. I FULLY agree with 
> Jonathan Sadler
> > > that
> > > the LMP work should also be consistent with this requirement.
> > >
> > > Regards,
> > > Rajender Razdan
> > >
> > > -----Original Message-----
> > > From: John Drake [mailto:[e-mail]]
> > > Sent: Monday, November 25, 2002 11:24 AM
> > > To: [e-mail]
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > Jonathan,
> > >
> > > The various Test transport mechanisms that are currently 
> defined in
> > > draft-ietf-ccamp-lmp-test-sonet-sdh were added in 
> response to input from
> > > various carriers and organizations such as the OIF.  The 
> fact that the
> > > individual carriers have different requirements for the 
> contents of the
> > > various SDH/SONET overheads is also consistent with my reading of
> > Deborah's
> > > recent e-mail on this topic.
> > >
> > > Since one of the transport mechanisms, the J0/J1/J2 trace 
> correlation,
> > > allows the transport of T.50 characters, I think we're done wrt
> > > draft-ietf-ccamp-lmp-test-sonet-sdh.
> > >
> > > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding 
> that none of the
> > > work aimed at G.7714.1 is compatible with the T.50 requirement.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[e-mail]]
> > > Sent: Thursday, November 21, 2002 8:23 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > I think you forgot what my original message said.  It stated:
> > >
> > > > > As mentioned at the CCAMP meeting, the SDH trace 
> bytes (J0/J1/J2)
> > > > > have restrictions not only on the length of a trace 
> message and on
> > > > > the bits usable in a octet, but also on whether the 
> payload in the
> > > > > message uses printable ASCII characters.
> > > > >
> > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > message payload must utilize the printable characters 
> defined in
> > > > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > consistant with this requirement.
> > >
> > > I fail to see what is incorrect with the above.
> > >
> > > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe 
> methods for
> > > J0/J1/J2 that fall within the requirements of G.707, it 
> also includes
> > > methods that don't.  This situation SHOULD be resolved to 
> provide the
> > > greatest amount of interoperability while reducing the 
> number of trace
> > > methods that need to be implemented.
> > >
> > > I'm glad to see we agree on the fact that 
> draft-lang-ccamp-lmp-bootstrap
> > > only provides methods that fall outside the requirements 
> of G.707.  This
> > > situation MUST be resolved.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Wouldn't it be more precise to say that it is an issue with
> > > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[e-mail]]
> > > > Sent: Thursday, November 21, 2002 12:49 PM
> > > > To: John Drake
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: Re: J0/J1 encoding issues
> > > >
> > > > John -
> > > >
> > > > draft-lang-ccamp-lmp-bootstrap does not support Trace 
> Correlation.
> > > > Therefore, it is an issue.
> > > >
> > > > Jonathan Sadler
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Is it the case that if one chooses to use J0/J1/J2 
> Trace Correlation,
> > > then
> > > > > Jonathan Sadler's issue is a non-issue?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang
> > > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > > To: 'Brungard, Deborah A, ALASO '; 
> '[e-mail] ';
> > > > > 'ccamp '
> > > > > Subject: FW: J0/J1 encoding issues
> > > > >
> > > > > Deborah,
> > > > >   Thanks for the note. The option that Jonathan 
> mentioned is one of a
> > > > couple
> > > > > options we define for Jx. We defined other options to
> > > > > interwork with existing equipment without requiring 
> any changes to
> > > > > existing encodings (this would support both C1 and 
> T.50 requirements).
> > > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > > Correlation. We welcome additional comments from you 
> and others at
> > > > > T1X1.5/ITU.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brungard, Deborah A, ALASO
> > > > > To: [e-mail]; ccamp
> > > > > Sent: 11/21/2002 5:22 AM
> > > > > Subject: RE: J0/J1 encoding issues
> > > > >
> > > > > As Jonathan says, the current G.707 is using T.50. 
> And there's more.
> > > > > Example, for J0, one currently needs to support:
> > > > > - previously defined C1 (repeating one-byte)
> > > > > - T.50 (with format of G.707)
> > > > > - no J0 (for equipment not supporting).
> > > > >
> > > > > So already we have defined multiple applications for 
> this byte. Not to
> > > > > say, there will be not any new ones. Even ITU knows, 
> it never is
> > > > > final;-)
> > > > >
> > > > > For supporting LMP's use, we need to understand the 
> scenarios of use
> > > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > > inter-operator, applied for equipment installation 
> verification or
> > > > > service connection verification, etc. And hardware 
> implications.
> > > > >
> > > > > Actually, G.831 defines multiple uses depending if 
> inter or intra -
> > > > > including for intra-operator, support of routing/path 
> set-up (and
> > G.831
> > > > > was done years ago).
> > > > >
> > > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 
> 5, contribute
> > the
> > > > > proposal for the meeting and we can start the 
> discussion. The next
> > ITU-T
> > > > > meeting is in January. If the LMP editors need help 
> on our T1X1.5
> > > > > process, just ask.
> > > > >
> > > > > Deborah
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Sadler [mailto:[e-mail]]
> > > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > > To: ccamp
> > > > > Subject: J0/J1 encoding issues
> > > > >
> > > > > All -
> > > > >
> > > > > As mentioned at the CCAMP meeting, the SDH trace 
> bytes (J0/J1/J2)
> > > > > have restrictions not only on the length of a trace 
> message and on
> > > > > the bits usable in a octet, but also on whether the 
> payload in the
> > > > > message uses printable ASCII characters.
> > > > >
> > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > message payload must utilize the printable characters 
> defined in
> > > > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > consistant with this requirement.
> > > > >
> > > > > This message is being sent to document this issue.  
> It is not a
> > > > > statement that no other issues exist -- I expect that 
> the appropriate
> > > > > experts in the ITU will review the rest of these two 
> drafts and
> > > > > provide appropriate comment.
> > > > >
> > > > > Jonathan Sadler
> > >
> > > (I disclaim the disclaimer that follows this message.)
> > > ============================================================
> > > The information contained in this message may be privileged
> > > and confidential and protected from disclosure.  If the
> > > reader of this message is not the intended recipient, or an
> > > employee or agent responsible for delivering this message to
> > > the intended recipient, you are hereby notified that any
> > > reproduction, dissemination or distribution of this
> > > communication is strictly prohibited. If you have received
> > > this communication in error, please notify us immediately by
> > > replying to the message and deleting it from your computer.
> > >
> > > Thank you.
> > > Tellabs
> > > ============================================================
> > ============================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> > 
> > Thank you.
> > Tellabs
> > ============================================================
>