RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

["Jonathan Lang" <[e-mail]>]

Kireeti,

  Fine, send it as is.

-Jonathan

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Sunday, May 11, 2003 11:23 PM
> To: [e-mail]
> Cc: [e-mail]; Wijnen, Bert (Bert); Ron Bonica 
> (E-mail); [e-mail]
> Subject: RE: Proposed response to the Liaison Statement on 
> LMP Link Verifi cation
> 
> 
> Hi All,
> 
> On Tue, 29 Apr 2003, Kireeti Kompella wrote:
> 
> > I will formulate a liaison statement in reply to T1X1 regarding 
> > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list.
> 
> Sorry for the tardy follow-up.  Here is the proposed response.
> 
> Please send your replies to the list (if you wish to reply 
> privately, include the Liaison Coordinator and the ADs in your reply).
> 
> Ideally, your reply should say one of:
>  - "Fine, send it as is"; OR
>  - "Please make the following changes", with _specific text_; OR
>  - "Do not send this response".
> 
> Please respond by COB Friday, May 16th.
> 
> Kireeti. 
> ==============================================================
> =========
> 
> Dear Mr. Biholar,
> 
> Regarding the following liaison:
> 
> TITLE: Liaison from T1X1 to IETF ccamp regarding
> 	draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
> TO: IETF ccamp Working Group
> CC: ITU-T Q.14/15 (for information)
> SOURCE*: T1X1
> FOR: Action
> DEADLINE: 9 June 2003
> PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic 
> Interconnection
> 
> We thank the T1X1 and the ITU-T for their review and the 
> incorporation of the LMP Test procedure into G.7714.1.
> 
> Based on information contained in the ITU and T1X1 liaison, 
> as well as subsequent e-mail exchanges on the CCAMP mailing 
> list, and in order to ensure proper interoperability in 
> legacy SDH/SONET networks as well as networks in which 
> G.7714.1 is deployed, it will be recommended by the editors 
> to the CCAMP community to support only the Jx trace 
> correlation procedure and not the in-band Jx procedure.  
> Pending agreement, the draft will be updated.
> 
> See inline for more detailed responses to specific points.
> 
> > Context of Application Space
> 
> <snip>
> 
> > It is currently our understanding that the use case
> > scenario for which this procedure is applied encompasses
> > both transport plane connectivity verification as well as 
> correlation 
> > of these entities with the control plane. ITU-T G.7714.1 is 
> focused on 
> > discovering the transport plane link connection end point 
> > relationships and verifying their connectivity.
> > This Recommendation defines two procedures for performing
> > the connectivity verification function, one of which
> > utilizes either the Jx or the DCC bytes of the server
> > signal (termed "in-service"). The other approach in
> > G.7714.1, termed as "out of service", corresponds to
> > inserting a test signal in the payload of the server
> > signal. Based on an analysis of the data link state
> > definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> > that the approach defined in the LMP test for physical
> > connectivity occurs in the context of the "out of service"
> > state (as described in G.7714.1).
> >
> > Please confirm this.
> 
> The subject document uses the Jx or DCC bytes to perform the 
> LMP Test procedure, but the The LMP Test procedure is done as 
> part of GMPLS link intialization, prior to the link being 
> available to carry user traffic.
> 
> > Usage of Jx Bytes
> >
> > In defining the Jx bytes within G.7714.1, the following
> > was taken into account:
> > 1. One consideration involved the case where the Discovery Agent is 
> > located in an external system, and an external interface is used by 
> > the Network Element to provision and receive the Trail 
> Trace message. 
> > As an existing text- oriented Man-Machine Language, such as 
> TL1, may 
> > be reused to provide this interface, it was decided that the
> > discovery message be limited to printable characters.
> > Specifically, the TTI characters should be limited to
> > printable characters as per T.50 with trailing NULLs or
> > SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> > of each byte could prematurely terminate the pattern or
> > trigger fault notification for certain hardware or
> > software implementations. The strategy chosen in G.7714.1
> > avoids the danger by limiting the information content of
> > each byte to 6 bits (84 bits total) and uses a base 64
> > coding according to RFC2045 to place the information in
> > the available bits.
> 
> The LMP test procedure described in the subject document 
> defines two usages of the Jx bytes.  The first is termed the 
> 'trace correlation transport mechanism' and it treats the Jx 
> bytes as an opaque bit stream.
> 
> This usage is completely consistent with the above.  GMPLS 
> identifiers are typically 32 bit numbers and as such are not 
> printable characters.  In networks that do not require that 
> the Jx bytes be printable, it is also possible to carry the 
> GMPLS identifiers directly in the Jx bytes.  This is termed 
> the 'Jx transport mechanism'.
> 
> > 2. Another consideration involved providing a means for 
> distinguishing 
> > this use of the Jx bytes from the traditional use for Trail Trace 
> > identifiers in new equipments. As a result, G.7714.1 includes a
> > distinguishing character ("+") as the first non-CRC byte
> > that will never appear as the first character of a TTI.
> > This requires modification of the trail termination
> > functions to prevent the raising of TTI mismatch
> > alarms during the connectivity verification process.
> 
> The selection of which LMP transport mechanism use in the LMP 
> Test procedure for a given link as well as the time at which 
> the Jx bytes are to be used for the LMP Test procedure is 
> under control of the GMPLS nodes at either end of the link, 
> so it is well understood by those nodes.  It is our 
> understanding, per G.806 section 6.1, that the LMP Test 
> procedure would be performed when the link is in the NMON 
> (not monitored state), and therefore intermediate SDH/SONET 
> equipment would not be performing non-intrusive monitoring.
> 
> > While the context for testing the transport plane connectivity is 
> > different between the two documents, they both use the Jx 
> bytes of the 
> > server signal, and we invite the IETF to determine the 
> appropriateness 
> > of the above aspects in their test signal definitions.
> 
> The trace correlation transport mechanism is completely 
> consistent with this.  The JX transport mechanism requires 
> additional identifiers (i.e., the Verify ID).
> 
> > Even if these considerations are not relevant to this 
> context, it will 
> > be necessary to augment G.783 equipment functions to recognize this 
> > new usage of Jx messages.
> 
> We would be happy to provide assistance to T1X1/ITU-T in 
> augmenting G.783 equipment functions to recognize the 
> additional capability for supporting GMPLS networking elements.
> 
> > Required Updates to SDH Equipment Specifications
> >
> > SDH equipment specifications as they currently exist 
> reflect the usage 
> > of the Jx bytes prior to the development of G.7714.1. ITU-T Study 
> > Group 15 has as a work item to revise these equipment functions to 
> > include support for these new functions. Specifically, this will 
> > involve updates to trail termination functions to generate and
> > receive the new messages and to avoid unnecessary alarms in
> > the case where the new messages are received.  In addition,
> > non-intrusive monitoring functions will need to be revised
> > so that unnecessary alarms are not raised when the
> > messages are observed en-route.  Whether or not there is
> > further alignment between the message formats used in
> > G.7714.1 and the subject draft, the new functions to
> > support the subject draft will also need to be reflected
> > in the atomic functions in G.783.  The sending and
> > receiving of these messages can be reflected in the trail
> > termination functions in a similar way to what we plan to
> > do for support of G.7714.1 functions.
> 
> We would be happy to provide assistance to T1X1/ITU-T in 
> augmenting G.783 equipment functions to recognize the 
> additional capability for supporting GMPLS networking elements.
> 
> > Terminology Differences
> 
> <snip>
> 
> > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> > the "up/free (in-service)" data link state appears to 
> correspond with 
> > what G.7714.1 refers to as "out-of- service".  This difference in 
> > terminology has resulted in different interpretations of 
> the context.  
> > Explaining the scenarios further in the lmp test document would be
> > beneficial in establishing a translation between the
> > differing uses of the same terms.  Within ITU-T, work is
> > being initiated of draft Rec. G.fame, Framework for ASON
> > Management, where control plane/management plane
> > interactions will be addressed.
> 
> We agree that terminology differences between IETF and ITU-T 
> wrt GMPLS have been confusing.  There is an ongoing effort 
> within CCAMP to work together with T1X1/ITU-T on bridging the 
> terminology gaps.  For example, there is a new Internet draft
> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered 
> in CCAMP to do this mapping for LMP.
> 
> > Further Study Items
> >
> > Following are some areas where further contributions are
> > requested:
> > 1.     For SDH equipment functions in G.783, it needs to
> > be understood whether the application of the lmp test
> > message requires revision of NIM (non-intrusive
> > monitoring) functions.  The reason for this is that the
> > test procedure is initiated between control entities at
> > the end-points of the trail, and intermediate points are
> > not necessarily aware that the test is taking place.  For 
> G.7714.1, it 
> > was felt important for any termination or NIM function to easily 
> > distinguish between the various uses of the Jx bytes.  It may be 
> > necessary for the subject draft to use a similarly easily 
> recognizable 
> > format.  If no revision to NIM functions is required for 
> the context 
> > of this draft, the architecture of the context for this
> > application (demonstrating why the NIM functions are not
> > required) should be reflected in G.803 and/or G.807/G.8080.
> 
> It is our understanding, per G.806 section 6.1, that
> the LMP Test procedure would be performed when the link is in 
> the NMON (not monitored state), and  therefore intermediate 
> SDH/SONET equipment would not be performing non-intrusive 
> monitoring. As described, the trace correlation procedure use 
> of Jx bytes is consistent with the current standards.
> 
> > 2.Determination of whether it would be possible to use the 
> identical 
> > message formats in the subject draft as in G.7714.1 for the 
> > connectivity verification function.
> 
> The trace correlation transport mechanism is completely 
> consistent with this.  The Jx transport mechanism requires 
> additional identifiers (i.e., the Verify ID).
> 
> > 3.Determination of whether it would be possible to use the same 
> > overall structure (distinguishing character, 4 bit message type, 80 
> > bit message body) if a different message format or 
> information content 
> > is required.
> 
> This is certainly possible (not applicable for the trace 
> correlation procedure).
> 
> > 4.Work is needed to clarify under what
> > configurations/states (for example: no VC-n signals
> > carrying client traffic) the lmp test message is
> > applicable over J0.  If the signal can be framed and J0
> > can be recovered, the Regenerator Section is considered
> > as "in service" from a transport plane perspective.  So unlike the 
> > J1/J2 case, the application of the lmp test message at the 
> Regenerator 
> > Section does not occur in an "out of service" state (from a 
> transport 
> > plane perspective).
> 
> Section 6.1 of G.806 refers to a "termination function part 
> of a trail, which is in the process of set-up" as in the NMON 
> state. LMP link verification is based on pre-service testing. 
>  Please let us know if we can be of any assistance in 
> updating the appropriate Recommendations to support the GMPLS 
> network element LMP capability. This is not applicable for 
> the trace correlation procedure.
> 
> > 5. Clarification of the usage of transport and control
> > names for transport resources in the subject draft, as described in 
> > G.8080 Amendment
> 
> The trace correlation transport mechanism supports a 
> separation of the transport and control plane identifiers.
> 
> > 6. Consideration of the ANSI 64-byte J1.
> 
> This was mistakenly deleted from the latest version of the 
> draft. This will be included in the next version.
> 
> Sincerely,
> Kireeti Kompella and Ron Bonica,
> Chairs of the CCAMP WG/IETF.
>