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.