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

[[e-mail]]

Fine, send it as is.

Kireeti Kompella wrote:
 > 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.
 >


-- 
Papadimitriou Dimitri
E-mail : [e-mail]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [e-mail]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]