[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Optical Link Interface - Correction
Forgot to attach the new NTIP draft.
Also, I meant "working on (4)", not (3).
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com
> -----Original Message-----
> From: Bala Rajagopalan
> Sent: Friday, July 27, 2001 9:28 AM
> To: 'Andre Fredette'; ccamp@ops.ietf.org
> Subject: RE: Optical Link Interface
>
>
> Andre:
>
> I believe you're counting me in the "agnostic" category.
> I hope this is not taken as "don't care", since I
> do have an interest in making a choice quickly.
>
> I have looked at the LMP-WDM draft (again) and the new
> NTIP draft sent by Osama (attached). I see the following:
>
> 1. Both these solutions gloss over the details of
> auto-discovery between OXCs and WDM. (Note: the
> issues are the same regardless of the protocol used
> and neither provides full details. Furthermore,
> the hardware requirements and actions under both
> are the same).
>
> 2. If we leave out (1), then the other functions are
> based on messaging over the control channel
> between the OXC and the WDM. This messaging
> can be done one way or the other.
>
> 3. Both require control channel maintenance using
> (simple) keepalive.
>
> 4. It seems LMP-WDM can be streamlined to make it
> more lean and mean.
>
> Unless there is a significant technical issue
> of one choice over the other, we have to consider
> the fact that LMP-WDM has the first mover advantage.
> Is it possible for
> the NTIP proponents to seriously consider working on
> (3)? Specifically, focus LMP-WDM on OLI requirements
> only and not carry any unrelated LMP concepts into
> LMP-WDM. Would this satisfy the design motivation for NTIP?
>
> Regards,
>
> Bala
>
>
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: braja@tellium.com
>
> > -----Original Message-----
> > From: Andre Fredette [mailto:fredette@photonex.com]
> > Sent: Thursday, July 26, 2001 2:52 PM
> > To: ccamp@ops.ietf.org
> > Subject: RE: Optical Link Interface
> >
> >
> > From my count on the mailing list we have the following
> > results so far:
> >
> > LMP-WDM: 8
> > NTIP: 3 (All from Nortel)
> > Agnostic: 1
> >
> > And then there are the other 16 co-authors of LMP-WDM who
> > haven't posted
> > (perhaps because they don't think they have any new points to add).
> >
> > Andre
> >
> > At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
> > >Kireeti,
> > >
> > >I have been following this thread with great interest. I
> > agree with your
> > >conclusion that we should pick one protocol and move forward.
> > >
> > >You are talking about WG reaching a consensus. I cannot see
> > how this is
> > >possible given the two very different views I see in the
> latest email
> > >exchanges.
> > >
> > >How can we resolve the current dispute? What forum should we
> > use to make
> > >a final decision on this?
> > >
> > >Martin
> > >
> > >-----Original Message-----
> > >From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > >Sent: Wednesday, July 25, 2001 9:57 PM
> > >To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
> > >osama@nortelnetworks.com
> > >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
> > >vasants@nortelnetworks.com
> > >Subject: RE: Optical Link Interface
> > >
> > >
> > >Hi Osama,
> > >
> > > > Even though I don't think reviving CR-LDP and RSVP-TE
> > history will get
> > >us
> > > > anywhere
> > >
> > >"Those who forget (ignore) history are doomed to repeat it."
> > >
> > >Yes, it makes for painful recollections. We're living with the
> > >consequences now, though, and I don't want to again.
> > >
> > > > the existence of two protocols here have proven to be useful.
> > >
> > >That's not what I'm hearing, either from customers, or from the
> > >WG (admittedly, the sample is small).
> > >
> > >Listen carefully: I don't want LMP-WDM and NTIP moving forward.
> > >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
> > >consensus is. LMP-WDM and LMP works too.
> > >
> > >So: you've got the WG chairs (scarred and grumpy), the ADs
> > >and TA (speak up if I'm misrepresenting you), and customers
> > >saying, Pick one protocol and move forward. Let's do that.
> > >And, please, as Vijay says, let's resolve this already.
> > >
> > >Kireeti.
> >
>
CCAMP WG V. Sahay
B. Narayanan
Internet Draft R. Ramaswami
Document: draft-sahay-ccamp-ntip-01.txt O. Aboul-Magd
B. Jamoussi
Nortel Networks
R. Jain
S. Dharanikota
Nayna Networks
R. Hartani
Caspian Networks
July 2001
Network Transport Interface Protocol (NTIP) for Photonic
Cross Connects (PXC)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This draft describes the transport network interface protocol (NTIP)
for photonic cross connects (PXC). NTIP is implemented between a PXC
and transport network element (TNEs), also known as line systems.
NTIP is a protocol that uses TCP/IP for the transport of information
related to defect notification, trace monitoring, adjacency
discovery, and diagnostic messages between directly attached PXC and
TNE. The use of TCP as the transport protocol ensures reliable and
in-sequence delivery of NTIP messages.
2. Conventions used in this document
Sahay Expires January 2002 1
Draft-sahay-ccamp-ntip-01.txt July 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Introduction
Fast restoration of failed light paths is critical for PXCs and it
requires support for fast and accurate failure detection. Most PXCs
do not look into the optical signals that flow through them. Some
can detect presence or loss of light on a port. However presence of
light does not necessarily mean that the light path is fine. For
example when a link fails, generators between the point of failure
and the PXC may inject an alarm indication signal (AIS) on a light
signal. Unless the PXC decodes the framing of the light signal
(possibly using some electrical circuitry), AIS will appear as
presence of light. Also, some of the DWDM equipment (also called
Transport Network Elements in this document) can control the
switching ON and OFF of the AIS by configuration (or on demand). This
feature can be leveraged to the advantage of the faster fault
detection and hence the recovery times.
Unlike the PXC, the transport network elements (TNE) attached to it
are aware of their equipment failure as well as the quality and
framing of the light paths passing through them. Failure information
can be dynamically conveyed from the TNE to the PXC using out of
band IP messaging.
The transport network interface protocol (NTIP) defines the set of
messages and the transport mechanism used for the exchange of
failure conditions. NTIP is implemented between the PXC and the TNE.
NTIP is an IP message handshake transported over an IP network. The
implementation of NTIP between TNE and PXC achieves the following
goals:
- Defect Notification: NTIP is used by the TNE to relay failure
conditions and precise link, fiber, and equipment status
notification to PXC. Defect reporting can be both event-driven
(e.g., link failures), polling-driven (e.g., regular link sanity
checks) or time-driven (e.g., periodic).
- Trace Monitoring: A PXC can use NTIP to request a TNE to monitor a
certain pattern in the overhead of a light path. This capability
could be used by PXC for validating light path identity.
- Diagnostics: NTIP could be used by OXC to request a TNE to perform
diagnostics on any port or channel.
- Adjacency Discovery: NTIP could be used by both PXC and TNE to
send and receive in band signals for automatic discovery of their
optical connectivity.
Sahay Expires January 2002 2
Draft-sahay-ccamp-ntip-01.txt July 2001
This draft describes NTIP procedures and messages to achieve its
design goals.
4. Reference Model
The current generation of PXCs will interoperate with opaque line
systems such as SONET regenerators, wavelength translators, etc.
Eventually when enough transparent line systems are deployed, PXCs
will interwork with them leading to an all optical network (AON).
The need for NTIP exists in both cases. The following reference
model focuses on interoperation of PXCs with opaque line systems.
A reference model is shown in Figure 1. TNE are used to connect PXC
ports to the transport system. TNE could be a set of OEO devices
followed by a DWDM mux as shown in Figure 1. A TNE regenerates the
signal coming from the PXC and might be capable of translating the
wavelength. The key features of a TNE in the reference model are its
ability to detect defects on its ports and to communicate defect
information back to the PXC using NTIP.
Drop Line
Side side
| |
| |
+---------+| TNE | |\ /| TNE +---------+
| +---|V +---+V | \ / | +---+ |---+ |
| |Por|->| |->| \ / |<-| |<-|Por| |
| | t| |---| | \ / | |---| | t| |
| | |<-| |<-| \ / |->| |->| | |
| +---| +---+ | \=====>/ | +---+ |---+ |
| | | /<=====\ | | PXC |
| PXC +---| +---+ | / \ | +---+ |---+ |
| |Por|->| |->| / \ |<-| |<-|Por| |
| | t| |---| | / \ | |---| | t| |
| | |<-| |<-| / DWDM MUX \ |->| |->| | |
| +---| +---+ |/ \| +---+ |---+ |
|=========| |=========|
|controlle| +===+ +===+ |controlle|
| r |<>| | | |<>| r |
+---------+^ +===+ +===+ ^+---------+
| TNE TNE |
| controller controller |
NTIP NTIP
PXC = Photonic CrossConnect TNE = Transport Network Element
TX = Transmit RX = Receive
FIGURE 1: PXC to TNE Reference Configuration
Each PXC port consists of two unidirectional fibers, one for input
(RX) and one for output (TX). Four TNE ports are associated with
each PXC port (RX and TX). The TNE port that is connected to PXC is
referred to as drop-side port, and the one that is connected to the
Sahay Expires January 2002 3
Draft-sahay-ccamp-ntip-01.txt July 2001
line is called the line-side port. Figure 1 shows that a PXC will
communicate with several TNEs. On the other hand, a TNE only
communicates with a single PXC.
A TNE can detect failures on signals it receives. Additionally some
TNEs may be able to detect certain failures on their output ports
such as laser failure.
5. NTIP Overview
5.1 Configuration
Whenever automatic discovery is not available, a PXC is provisioned
with information on how its ports are connected to TNE. It is also
provisioned with the primary and the secondary IP addresses of each
TNE connected to it.
NTIP defines a set of configurable parameters such as protocol
timers, retry counts, etc. Those parameters could be assigned
default values or allowed to be set as needed or negotiated.
5.2 Registration
As a TNE starts up, it registers with the PXC whose address is
configured in it. A TNE registers by opening a TCP session with the
PXC, and sending a registration request message. TNE registration
allows PXC to create its internal context structure for this
particular TNE.
5.3 Keep Alive
NTIP utilizes keep alive messages. Keep alive messages are exchanged
periodically between TNE and PXC to verify the sanity of the
connection. The keep alive message interval is a configurable
parameter.
5.4 Automatic Discovery
A PXC might have hundreds or even thousands of ports. Manual entries
of port adjacency between PXC and TNEs connected to it is tedious
and error prone. Furthermore manual entry has to be repeated every
time there is change in adjacency due to, for instance, re-cabling.
One application of the NTIP interface is for use in automatic
adjacency discovery between PXC and TNEs. For that purpose it is
assumed that the TNE is aware of its ports mapping, i.e. the mapping
between its drop side TX and RX ports, and its line side ports. This
mapping is mad available using NTIP to the auto discovery process
(ADP).
The TNE drop side port is supposed to operate in one of two modes,
Pass-through and Insert. In the Insert mode the drop side TX inserts
an identity pattern into the signal overhead, e.g. J0. The PXC is
Sahay Expires January 2002 4
Draft-sahay-ccamp-ntip-01.txt July 2001
made aware of the TNE port identity patterns over the NTIP interface
using a MappingTable message. In the Pass-through mode, the TNE drop
side TX passes the signal without modification.
The auto discovery process starts with the PXC port establishing a
cross connect to a well-known Test RX as shown in Figure 2. The PXC
then sends a ModeSwitch message to the TNE to switch the TNE drop
side TX mode to the Insert mode. The TNE starts inserting its
identity pattern (could be a system wide unique id or a trail trace
id).
+-------------+ +----+----+
| |---->| RX | TX |--->
| | +----+----+
| PXC |
| | +----+----+
| |<----| TX | RX |<---
| | +----+----+
+-------------+
| ^ <-- NTIP-->
| |
V |
+---+ +---+
| | | |
+---+ +---+
Test Test
RX TX
Figure 2: Auto Discovery Configuration
The Test RX is requested to report the Identity message it sees. The
ADP maps the identity message to the drop side TX port id and the
PXC port id. To verify mapping, the Test TX is requested to send the
same identity pattern to the TNE drop side RX over NTIP using the
discovered PXC port. The TNE drop side RX verify the received
identity pattern and reports match pr mismatch.
The Test TX/RX could be internal or external to the PXC. In the case
of external Test TX/RX, communication would be done over NTIP
interface.
The procedure for auto-discovery is also applicable for link
verification.
5.5 Defect Monitoring
Defect monitoring is initiated by the PXC by telling the TNE which
ports to monitor for defects (signal degradation, loss of light,
etc.). Defect monitoring will be initiated by the PXC after setting
a light path through a TNE port. PXC terminates defect monitoring on
a port before it disconnects the light path on that port.
Sahay Expires January 2002 5
Draft-sahay-ccamp-ntip-01.txt July 2001
5.6 Trace Monitoring
Trace monitoring ensures that a light path is connected to the
correct client. A trace (light path Id) is injected by the client in
the light path. After setting up a light path, PXC will request TNE
to match the supplied trace id with that in the light path. The TNE
informs the PXC in case of a mismatch.
Trace Id is a pattern that can be injected and monitored in a light
path without affecting its payload. A few different alternative ways
of implementing it are possible. Trace Id may be injected in wrapper
or as a pilot tone. NTIP supports all of them.
The PXC discontinue the trace monitoring process for a particular
light path before deleting it.
5.7 Status Request/Response
Status request is initiated by the PXC and is triggered by an NTIP
user application, e.g. NMS. Status response contains the status of
the requested to TNE ports. It is sent by the TNE in response to
status request.
5.8 Batching of Messages
To reduce message traffic, TNE can pack several defect notification
messages into a single message. Latency could be experienced as a
result of batching since TNE has to hold off sending defects for an
amount of time necessary to collect enough defects.
5.9 Resynchronization
Resynchronization is needed every time an NTIP session restarts. An
NTIP session could restart due to TCP connection failure, PXC
restart due to internal reasons, e.g. control plan restart or PXC
restart, TNE restart, or as a result of a deletion of the NTIP
session due to time out.
Each TNE keeps track of its NTIP session. If the session is deleted,
it attempts to create another session over TCP/IP periodically. The
time it waits before initiating a second attempt is a configurable
parameter.
Once TNE succeeds in creating a TCP connection with PXC, it repeats
the registration procedure as mentioned in section 5.2. Upon
receiving the registration request, the PXC goes into a
resynchronization phase requesting an update on the port status of
all TNE ports that it is interested in. The PXC confirms the end of
the synchronization phase to the TNE when it receives the status of
all the requested ports.
Resynchronization helps the reporting of failure events that would
have been missed by the PXC due to the NTIP session being down. It
Sahay Expires January 2002 6
Draft-sahay-ccamp-ntip-01.txt July 2001
also allows the TNE not to remember the defects monitoring commands
given before resynchronization.
5.10 TNE to PXC Transport
A single high availability router/switch is recommended for
connecting TNE to PXC. This transport arrangement is referred to as
NTIP transport network. TNE defect messages are required to reach
the PXC with little delays. It is recommended that the NTIP network
supports the priority handling of packets, e.g. differentiated
services. Messages related to defect reporting are transported with
high priority. All other messages, that are not time critical, are
transported using a lower priority.
NTIP messages are transported reliably using TCP as the transport
protocol. The use of TCP also ensures in-sequence delivery of NTIP
messages, hence relieving the protocol developer from creating an
additional layer for reliable delivery.
Figure 3 shows the logical connectivity between PXC and TNE.
+-----+ +-----+
| | +--------------+ +----+ |
| | | |-------+----+ |--+
| PXC |---| IP Network |-------| |-+
| | | | +----+
| | +-------------+ TNEs
+-----+
|<---------------------------->|
TCP Session
FIGURE 3: PXC-TNE Logical Connectivity
Figure 3 emphasizes the fact that a PXC communicates with several
TNEs while a TNE only communicates with a single PXC.
5.11 Defect Types
A TNE will report the following defects to PXC.
- Signal Degrade (SD): TNE reports this type of failure when the
light signal on one of its ports degrades below a configured
threshold.
- Signal Fails (SF): TNE reports SF to PXC when the incoming signal
fails on one of its ports.
- AIS: TNE reports AIS to PXC when it detects AIS-LINE on one of its
ports.
- Trace Mismatch: TNE reports Trace Mismatch when it mismatch is
detected by one of its ports between an injected pattern and the
expected pattern.
Sahay Expires January 2002 7
Draft-sahay-ccamp-ntip-01.txt July 2001
- Equipment Failure: TNE will notify PXC of equipment failure (e.g.
OEO card or laser failure on the transport side) and the port
number that suffered the failure.
6.0 NTIP and OLI Requirements
The requirements for the interface between PXC and the line system,
denoted as OLI (Optical Link Interface), have been discusses in [3].
Most of those requirements have been taken from the earlier version
of this draft that was presented back in March during the IETF 50
meeting. In this section we discuss how far NTIP satisfies those
requirements.
6.1 General OLI Characteristics
General OLI requirements are reliabile, secure, and simple. NTIP
meets the reliability and security requirements by employing TCP as
its transport mechanism. TCP provide reliable and orderly
transmission of NTIP messages. Furthermore it provides a flow
control mechanism that allows for bulk transmission of NTIP
messages. The TCP window mechanism paces messages for cases where
the traffic volume increase for instance due to, for instance, re-
synchronization.
Line systems (TNEs) do not usually have much memory, and can only
keep a limited amount of state. NTIP achieves simplicity by
establishing a master-slave, as opposed to peer, relationship
between the PXC and TNEs. This minimizes the amount of states kept
at the TNE and makes efficient used of the limited memory available.
6.2 OLI Functionality
OLI basic functionality as defined in [3] are: neighbor discovery,
control channel maintenance, re-synchronization, connectivity
discovery, fault management, and link property information.
Neighbor discovery and control channel maintenance are achieved in
NTIP by means of a simple registration and keep alive procedures.
Connectivity discovery has been discussed in section 5.4. It allows
for the automatic discovery and mapping between PXC ports and TNE
ports.
Fault management and re-synchronization have always been the main
focus of NTIP as discussed in a previous revision of this draft.
Fault management includes fault notification and trace monitoring,
both have originally been introduced in a previous revision of this
draft. NTIP introduced the notion of priority handing of fault
notification messages to expedite light path recovery and
restoration in the order of few tens ms.
Sahay Expires January 2002 8
Draft-sahay-ccamp-ntip-01.txt July 2001
Trace monitoring has ingeniously been introduced by NTIP and has
been adopted as one of the main requirements of OLI.
Most of the link property information, e.g. SRLG and span length can
be configured. If necessary they can be added to NTIP with minor
modifications.
7.0 NTIP Messages and Procedures
All NTIP messages start with the following two fields:
NTIP Vers:
2-byte field that contains the NTIP protocol version number.
Type:
2-byte field that contains the message type
The version number provides the features supported by the other side
of the NTIP communication. It is only verified at the establishment
of NTIP session, and is used during registration and
resynchronization states.
7.1 Registration Message
The format of the Registration Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ TNE Model Number +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = REG-REQ
TNE Model Number:
16-byte filed that specifies the TNE model number
Procedure:
Registration Message is sent by the TNE to the PXC at start up. If
a PXC receives a Registration Message with a different NTIP Vers
than expected it may take one of the following actions:
- Reject the registration request
Sahay Expires January 2002 9
Draft-sahay-ccamp-ntip-01.txt July 2001
- Reject the registration request if the received NTIP Vers differs
by more than an allowed difference. If the difference is
acceptable, then the message set common to the two versions will
be supported.
7.2 Registration Complete Message
The format of the Registration Complete Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = REG-COMPLETE
Procedure:
The Registration Complete Message is sent by PXC to TNE indicating
a successful completion of the registration. The message is sent
only during the initial synchronization phase.
7.3 KeepAlive Message
The format of the KeepAlive Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = KEEP-ALIVE-REQ
Procedure:
The KeepAlive Message is sent by the TNE to PXC every T-keep-alive-
interval seconds (the default is 60 seconds). If PXC does not receive
a KeepAlive Message every T-keep-alive-timeout (t-keep-alive-timeout
= 3*T-keep-alive-interval), it takes down the NTIP session.
7.4 KeepAlive Response Message
The format of the KeepAlive Response Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Sahay Expires January 2002 10
Draft-sahay-ccamp-ntip-01.txt July 2001
Type = KEEP-ALIVE_RES
Procedure:
The KeepAlive Response Message is sent by PXC to TNE in response to
a KeepAlive Message.
7.5 Monitor Request Message
The format of the Monitor Request Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of Ports | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AR |DM | TType |MT | Tr Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Trace ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AR |DM | TType |MT | Tr Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Trace ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = MON-REQ
No. of Ports:
2-byte field that contains the number of ports reported in this
message.
Port Address:
4-byte field that is formatted as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sahay Expires January 2002 11
Draft-sahay-ccamp-ntip-01.txt July 2001
| shelf | slot | Sub Slot | port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alarm Reporting, AR:
2-bit field that indicates start, stop, or no change to alarm
reporting.
Defect Monitoring, DM:
2-bit field that indicates start, stop, or no change to failure
monitoring.
Trace Type, TType:
4-bit used to indicate the trace type. Possible types are, pilot
tone, wrapper, J0 bytes.
Monitor of Trace, MT:
2-bit field that indicates start, stop, or no change to trace
monitoring
Trace Length, Tr Len:
6-bit field that indicates the length of the monitored trace.
Trace ID:
Up to 63 bytes. It defines the trace to be monitored. User could
treat the Trace ID as ASCII or binary
Procedure:
The Monitor Request Message is sent by PXC to TNE. After setting a
light path through TNE, PXC will send Monitor Request Message
indicating the start of defect monitoring and the list of monitored
ports. Before disconnecting a light path, PXC sends Monitor Request
Message with DM set to stop indicating the end of the defect
monitoring process.
The Monitor Request Message is also used for the start and the stop
of alarm reporting and trace monitoring. Upon the start of trace
monitoring, the PXC supplies the Trace ID to be compared to that in
the light path (say, in SONET J0 bytes, or in wrapper, or pilot
tone). Trace ID is not included in the Monitor Request Message when
MT is set to stop or no change.
7.6 Defect Notification
The format for the Defect Notification Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sahay Expires January 2002 12
Draft-sahay-ccamp-ntip-01.txt July 2001
| No. of Ports | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FS | FT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FS | FT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = DEFECT-NOTIFICATION
Failure Status, FS:
2-bit field that indicates fail or clear.
Failure Type, FT:
1-byte filed that indicates the failure (defect) type as discussed
in section 5.10.
Procedure:
The Defect Notification Message is sent by the TNE in response to a
PXC Monitor Request Message. The Defect Notification Message is
sent with the highest possible priority to reach the destination
PXC in a timely fashion.
7.7 Status Request Message
The format of the Status Request Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of Ports | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sahay Expires January 2002 13
Draft-sahay-ccamp-ntip-01.txt July 2001
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = STATUS-REQ
Tag:
A 4-bit field that is used for message identification
Procedure:
The Status Request Message is sent by PXC to TNE to solicit the
status of some or all of the TNE ports. Status Request Message
could also be sent to query the status of a previously issued
Monitor Request Message.
7.8 Status Response Message
The format of the Status Response Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of Ports | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | CStat | Dyn Stat | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | CStat | Dyn Stat | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = STATUS-RESP
Configuration Status, CStat:
4-bit field that indicates the provisioned state of a TNE port. It
indicates whether the port is enabled or disabled.
Dynamic State, Dyn Stat:
Sahay Expires January 2002 14
Draft-sahay-ccamp-ntip-01.txt July 2001
1-byte field that indicates the failure type experience by a TNE
port.
Procedure:
The Status Response Message is sent from TNE to PXC. A TNE sends a
Status Response Message in response to a Status Request Message.
For each port requested, the Status Response Message includes a
configuration status (enabled or disabled), and a dynamic port
defect status that specify the failure type as discussed in
section 5.10.
7.9 Configuration Update
The format of the Configuration Update Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTIP Vers | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of Ports | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CStat | Dyn Stat | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CStat | Dyn Stat | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Type = CONFIG-UPDATE
Procedure:
The Configuration Update Message is sent unsolicited by TNE to
PXC. It is used for dynamically modifying the configuration while
in operation.
8. Security Considerations
This draft does not introduce any new security issues.
9. References
Sahay Expires January 2002 15
Draft-sahay-ccamp-ntip-01.txt July 2001
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 A. Fredette, Editor, “ Optical Link Interface Requirements”,
draft-many-oli-reqts-00.txt, work in progress, June 2001
10. Author's Addresses
Vasant Sahay
Nortel Networks
2305 Mission College Blvd
Santa Clara, CA 95054, USA
Phone: 408-565-4601
E.mail: vasants@nortelnetworks.com
Rajiv Ramaswami
Nortel Networks
2305 Mission College Blvd
Santa Clara, CA 95054, USA
Phone: 408-565-4621
Email: rajiv@nortelnetworks.com
Babu Narayanan
Nortel Networks
2305 Mission College Blvd
Santa Clara, CA 95054, USA
Phone: 408-565-4537
Email: bon@nortelnetworks.com
Osama S. Aboul-Magd
Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y 4H7
Phone: 613-763-5827
Email: osama@nortelnetworks.com
Bilel Jamoussi
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821, USA
Phone: 978-288-4506
Email: jamoussi@nortelnetworks.com
Sahay Expires January 2002 16
Draft-sahay-ccamp-ntip-01.txt July 2001
Raj Jain
Nayna Networks, Inc.
157 Topaz St
Milpitas, CA 95035, USA
Phone: 408-956-8000 Ext 309
Email: raj@nayna.com
Sudheer Dharanikota
Nayna Networks, Inc.
157 Topaz St
Milpitas, CA 95035, USA
Phone: 408-956-8000 Ext 357
Email: Sudheer@nayna.com
Riad Hartani
Caspian Networks
170 Bytech Drive
San Jose, CA 95134, USA
Phone: 408-382-5216
Email: riad@caspiannetworks.com
Sahay Expires January 2002 17
Draft-sahay-ccamp-ntip-01.txt July 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Sahay Expires January 2002 18