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

Re: Proposed response to the Liaison Statement on LMP Link Verification

All,

I have a few comments on the proposed response to the Liaison Statement from T1-X1 on LMP Link Verification.

It seems to me that the response agrees that the application is the same, verifying the transport connectivity between two points. However no mention is made as to why it is neither possible nor desirable to use the same message format, thereby reducing the amount of variation in the world.

One unwanted consequence of three Jx formats is equipment burden. Why should equipment be burdened with three variations, when two are quite sufficient? Part of this burden is unnecessary behaviour for equipment to sort out which format is being used, provisioning of the choice, or simply being non interoperable.

A single format, which is useful in non green field applications, makes a lot of sense.

I also have a few specific comments inline.

Regards

George Newsome


Wijnen, Bert (Bert) wrote:

Thnaks for the proposed response.

It would be good if people could tell us if they agree or disagree
and if they disagree, then pls explain why.

If the response is acceptable, then it sounds to me that at least
there would be no impact on the draft-ietf-ccamp-lmp-08.txt
document, which is currently in IETF Last Call. Since we had split
the SONET/SDH material off into a separate document, my initial
evaluation made me think that the draft-ietf-ccamp-lmp-08.txt
would not have any ITU-T/T1X1 issues/concerns. The liason statement
did refer to it a few times and so I started to worry, but from
the (proposed) response it seems there is no isseu.

Would be good to get at least confimration of that by the end of the Last Call, and that is April 24th.

Thanks,
Bert

-----Original Message-----
From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com]
Sent: vrijdag 18 april 2003 22:25
To: ccamp@ops.ietf.org
Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be
Subject: FW: Proposed response to the Liaison Statement on ASON Routing


All,

Here's a proposed response to the Liaison Statement from T1-X1 on LMP
Link Verification, posted April 11, 2003.

Thanks,
Jonathan & Dimitri
--------------------------------------------------------------------
Dear Mr. Biholar,



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.

Yes, this is correct
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.

We understand that a general transport plane discovery agent application
such as G.7714.1 may want to limit the format to printable characters. However, LMP is a subset of the GMPLS control plane where no such constraint exists. As such, we don't think LMP link verification needs to be constrained to be printable characters.

This does not give any reason as to why LMP could not or should not use
this limitation. When GMPLS is retrofitted onto todays networks, the
same limitation will be there for the same reasons G.7714.1 took account
of it. LMP may be pre-service, but this is not the same as a green field application.




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.




We understand the need for this distinguishing character for the 
G7714.1 in-service application; however, LMP link verification is designed

to be used before a link is put in service. It is our understanding

per G.806 section 6.1, when a TTP is not in service, it is in 
the NMON state (not monitored)."







Many network elements take the availability of an input signal as a 
trigger to switch into monitoring mode. However, even for those which do 
not, there does not seem to be a good reason for not using a common format.








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.




We agree the context is different.  We evaluated the above aspects and
we don't feel they are appropriate for LMP (see comments above).







I'm still looking for the rationale that led you to this conclusion.  I 
only see a statement.






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
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 understand that G7714.1 is addressing an in-service test 
procedure and needs to be concerned with NIM (and non-support of G7714.1

by legacy NIM). The LMP test procedure is a pre-service 
application. We will be happy to work with T1X1/ITU SG15 to 
augment G.783 to recognize the additional capability for GMPLS 
networking elements.





It seems to me that having yet another format to do the same thing, and

which cannot be interleaved with normal tracing, is not an additional 
capability, but less capability.






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 wrt 
GMPLS have been confusing. There is an ongoing effort within 
CCAMP to work together with ITU/T1X1 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.




We understand that G7714.1 is addressing an in-service test 
procedure and needs to be concerned with NIM (and non-support of G7714.1

by legacy NIM). The LMP test procedure is a pre-service 
application. Can you clarify how "pre-service" applications impact G.803/G.807/G.8080? If we

can provide assistance in updating these Recommendations to

reflect LMP applications, please let us know.



G.803/G.807/G.8080? If we can provide assistance in updating 
these Recommendations to reflect LMP applications, please let us 
know.




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.




We have evaluated the current formats in G.7714.1 and we believe are
inappropriate for the usage of LMP.





Some rationale for this belief would be most useful.







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.




As mentioned above, we believe the overall message structure and
constraints are inappropriate for LMP.







I don't see answers to the above questions re technical feasibility, and 
belief is not a reason for not using the same format in the interests of 
reducing variation.






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.






5. Clarification of the usage of transport and control
names for transport resources in the subject draft, as
described in G.8080 Amendment




LMP defines a TRACE object when a separation between data and control
plane name space is requested.





I'm afraid that I don't understand this answer.







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.






Hopefully, this will not create yet another format.