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

[Dieter Beller <[e-mail]>]

Kireeti and all,

Fine, send it as is


Dieter


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.
>