[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on LMP
Baktha,
Thanks for the comments. Please see responses inline.
Thanks,
Jonathan
>-----Original Message-----
>From: Baktha Muralidharan [mailto:muralidb@cisco.com]
>Sent: Tuesday, November 20, 2001 11:22 AM
>To: ccamp@ops.ietf.org
>Subject: Comments on LMP
>
>
>Hello,
> Please find attached my comments; Beside the few I list
immediately below, I
> have embedded most of my comments in the document, to make it easier
to read.
>
> My comments are prefixed BM>
>
>Thanks,
>/Baktha
>
>---------------------------------------------------------------------------
--------------
>------
>1. Remove all references to TLVs. We have changed over to Objects.
done.
>2. Draft requires that link summary be sent periodically until an ack/nack
or timeout.
>
> Whenever a link summary is sent, the expected outcomes are either a
timeout or an
> ack/nack, isn't it?
> It is not clear then as to whether we recommend that the "periodic
transmission of
> link summary" to be stopped upon a timeout. If that is not what we are
recommending,
> i.e. we are recommending sending of link summary regardless of whether
we get a
> response or not, the above statement is unnecessary and I believe is
actually
> confusing.
If a timeout occurs, periodic transmission of link summary should be
stopped.
>3. [Parameter] Negotiability is described in terms of objects. Some objects
have
> subobjects and/or several attributes. Negotiability at these "lower
granularities"
> need to be spelt out.
>
> For example, consider the DATA LINK object; it is negotiable. And so, are
its
> subobjects. The data link sub-object carry interface switching
capability, bandwidth
> and encoding type. Can we interpret then that ALL of these are
negotiable parameters?.
> If they are, spelling them out would help.
Having negotiable parameters doesn't ensure convergence as the acceptable
parameter list isn't guaranteed to overlap. As such, I'm not sure it's
necessary to define negotiability at the "lower granularities".
>4. Under TE Link FSM, evDCDown is interpreted as "Last data channel of TE
Link has been
> removed
> Under data bearing link evDCDown is described as "data link is no longer
available".
> Administratively shutting down a data bearing link could fit the "no
longer available"
> description. Yet, the data bearing link could well be a member of a TE
Link (i.e.
> might not have been removed). Suggest using the same description.
The difference is that the TE Link event is referring to a Data Link being
removed from the resource pool, whereas the Data Link event is referring to
availability.
Please see rest of the comments to be embedded; look for lines starting with
BM>
==========================================================================
<snip>
1. Introduction
<snip>
For the purposes of this document, a data-bearing link may be either
a "port" or a "component link" depending on its multiplexing
capability; component links are multiplex capable, whereas ports are
not multiplex capable. This distinction is important since the
management of such links (including, for example, resource
allocation, label assignment, and their physical verification) is
different based on their multiplexing capability. For example, a
SONET crossconnect with OC-192 interfaces may be able to demultiplex
the OC-192 stream into four OC-48 streams. If multiple interfaces
are grouped together into a single TE link using link bundling
[BUNDLE], then the link resources must be identified using three
levels: TE link Id, component interface Id, and timeslot label.
Resource allocation happens at the lowest level (timeslots), but
physical connectivity happens at the component link level. As
another example, consider the case where a PXC transparently
switches OC-192 lightpaths. If multiple interfaces are once again
grouped together into a single TE link, then link bundling [BUNDLE]
is not required and only two levels of identification are required:
TE link Id and port Id. In this case, both resource allocation and
physical connectivity happen at the lowest level (i.e. port level).
BM> It looks like a TE Link is a "group of interfaces", regardless
BM> of whether they are bundled.
BM> Why "group" multiple interfaces (into a TE Link), if bundling
BM> and the associated benefits are the not the objective?
[Jonathan] The purpose of forming a TE link is "to group/map the information
about certain physical resources (and their properties) into the information
that is used by Constrained SPF for the purpose of path computation, and by
GMPLS signaling." (see draft-ccamp-gmpls-routing). Bundling strictly refers
to the [BUNDLE] draft. You can have benefits from aggregation of interfaces
into a TE Link without using the [BUNDLE] draft.
LMP is designed to support aggregation of one or more data-bearing
links into a TE link (either ports into TE links, or component links
into TE links).
BM>
BM> An example of "unbundled aggregation of data links into a
BM> TE Link" would greatly help to clear up
BM>
[Jonathan] This is given 2 paragraphs above. I can see about adding more
detail to clarify...
2. LMP Overview
The two core procedures of LMP are control channel management and
link property correlation. Control channel management is used to
establish and maintain control channels between adjacent nodes.
This is done using a Config message exchange and a fast keep-alive
mechanism between the nodes. The latter is required if lower-level
mechanisms are not available to detect control channel failures.
Link property correlation is used to synchronize the TE link
properties and verify configuration.
LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. The two directions of the
BM> Aren't control channels always bidirectional?. The successful
BM> config message exchange always marks the "bidirectional
BM> control channel establishment", isn't it?
BM> Suggest removing the word bidirectional from references to IPCC.
I don't think it hurts to say it explicitly.
control channel are coupled together using the LMP Config message
exchange. All LMP messages are IP encoded [except in some cases,
the Test Message which may be limited by the transport mechanism for
in-band messaging]. The link level encoding of the control channel
is outside the scope of this document.
Lang et al [Page 4]
Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001
An "LMP adjacency" is formed between two nodes when at least one bi-
directional control channel is established between them. Multiple
control channels may be active simultaneously for each adjacency;
control channel parameters, however, MUST be individually negotiated
for each control channel. If the LMP fast keep-alive is used over a
control channel, LMP Hello messages MUST be exchanged by the
adjacent nodes over the control channel. Other LMP messages MAY be
transmitted over any of the active control channels between a pair
of adjacent nodes. One or more active control channels may be
grouped into a logical control channel for signaling, routing, and
link property correlation purposes.
BM> This (the concept of logical control channel) applies to an
implementation's
BM> treatment of multiple control channels and should be removed to avoid
confusion.
BM> Logical control channels are not discussed elsewhere in the document.
[Jonathan] For practical purposes, I think the concept is important. The
fact that multiple LMP control channels is exposed as a single logical
control channel for higher layers is a key feature. This allows only a
single adjacency at the higher layers, while underneath you can have
multiple LMP adjacencies.
The link property correlation function of LMP is designed to
aggregate multiple data links (ports or component links) into a TE
link and to synchronize the properties of the TE link. As part of
the link property correlation function, a LinkSummary message
exchange is defined. The LinkSummary message includes the local and
remote TE Link Ids, a list of all data glinks that comprise the TE
BM> links
[Jonathan] done
link, and various link properties. A LinkSummaryAck or
LinkSummaryNack message MUST be sent in response to the receipt of a
LinkSummary message indicating agreement or disagreement on the link
properties.
<snip>
For the LMP link connectivity verification procedure, the free
(unallocated) data-bearing links MUST be opaque (i.e., able to be
terminated); however, once a data link is allocated, it may become
transparent. The LMP link connectivity verification procedure is
coordinated using a BeginVerify message exchange over a control
channel. To support various degrees of transparency (e.g.,
examining overhead bytes, terminating the payload, etc.), and hence,
different mechanisms to transport the Test messages, a Verify
Transport Mechanism is included in the BeginVerify and
BeginVerifyAck messages. Note that there is no requirement that all
data-bearing links must be terminated simultaneously, but at a
minimum, it must be possible to terminate them one at a time. There
is also no requirement that the control channel and TE link use the
same physical medium; however, the control channel MUST terminate on
the same two nodes that the TE link spans. Since the BeginVerify
BM> This is true for ALL LMP procedures, not just for connectivity
BM> verification. i.e. CC, by definition, is between a pair of neighbors.
<snip>
3. Control Channel Management
3.2. Hello Protocol
<snip>
3.2.3. Control Channel Down
To allow bringing a control channel DOWN gracefully for
administration purposes, a ControlChannelDown flag is available in
the Common Header of LMP packets. When data links are still in use
between a pair of nodes, a control channel SHOULD only be taken down
administratively when there are other active control channels that
can be used to manage the data links.
When bringing a control channel DOWN administratively, a node MUST
set the ControlChannelDown flag in all LMP messages sent over the
control channel. The node may stop sending Hello messages after
HelloDeadInterval seconds have passed, or if it receives an LMP
message over the same control channel with the ControlChannelDown
flag set.
When a node receives an LMP packet with the ControlChannelDown flag
set, it SHOULD send a Hello message with the ControlChannelDown flag
set and move the control channel to the Down state.
BM> On the receiving node, suggest transitioning to CONFSND state rather
BM> than DOWN state.. otherwise, it could not automatically get into
BM> config procedure- i.e. would need a trigger/event
BM> On the sending side, the trigger is the operator command to bring up
BM> the control channel
As it stands, an implementation may have an automatic trigger taking you
from Down to CONFSND or CONFRCV.
<snip>
4. Link Property Correlation
<snip>
Each TE link has an identifier (Link_Id) that is assigned at each
end of the link. These identifiers MUST be the same type (i.e,
IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is
assigned an identifier (Interface_Id) at each end. These
identifiers MUST be the same type at both ends.
BM> Why the restriction that both ends of a TE Link have to use the same
BM> identification?
[Jonathan] Having the same type of identification is just a restriction of
IP architecture (as in IP you can't have a link whose one end is numbered
and another is unnumbered).
<snip>
7. Message_Id Usage
Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order
messages can be identified by examining the value in the Message_Id
field.
If the message is a Config message, and the Message_Id value is less
than the largest Message_Id value previously received from the
sender for the CCID, then the message SHOULD be treated as being out
of order.
If the message is a LinkSummary message and the Message_Id value is
less than the largest Message_Id value previously received from the
sender for the TE Link, then the message SHOULD be treated as being
out of order.
BM> Isn't this logic true for link verification as well?
[Jonathan] no. Out-of-order link verification messages should be accepted.
<snip>
8. Graceful Restart
This section describes the mechanism to resynchronize the LMP state
after a control plane restart. A control plane restart may occur
when bringing up the first control channel after an LMP adjacency
has failed, or as a result of an LMP component restart. The latter
is detected by setting the "Control Plane Restart" bit in the Common
BM> Isn't the bit called LMP Restart?
[Jonathan] yes. I've corrected the text as you suggest.
<snip>
12.
LMP Finite State Machines
<snip>
12.2.
TE Link FSM
The TE Link FSM defines the states and logics of operation of an LMP
TE Link.
12.2.1. TE Link States
An LMP TE link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link and is
usually associated with a specific type of LMP message that is
periodically transmitted to the far end via the associated control
channel or in-band via the data links.
Down: There are no data links allocated to the TE link.
Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP
neighbor.
BM> I guess we are saying that once initially synchronized, subsequent
changes
BM> to TE Links that cause link summary to run could happen whilst the TE
Link
BM> is still in UP state.
[Jonathan] yes
BM> In the middle of the day, is the IDs and/or other properties
BM> of links are changed such that a TE Links go out of synchronization,
BM> should we go back to "Init" state?, such that the above definition of
BM> Init state is observed all the time?
[Jonathan] It doesn't make sense to change TE link properties if it is part
of a data connection.
Up: This is the normal operational state of the TE link. At
least one primary CC is required to be operational
between the nodes sharing the TE link.
Degraded: In this state, all primary CCs are down, but the TE link
still includes some allocated data links.
BM> Does the term "allocated" here refer to "allocated to data traffic"?
BM> I don't think so.. but could we be explicit?
[Jonathan]yes it does. I will change wording to say "includes some data
links that are allocated to data traffic."
BM> Related question. Whilst in Init state, if the last CC goes down,
BM> Shouldn't the TE Link go into degraded?
[Jonathan]no. Degraded implies data links are allocated to data traffic
<snip>
12.2.3. TE Link FSM Description
Figure 4 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram.
3,7,8
+--+
| |
| v
+--------+
| |
+------------>| Down |<---------+
| | | |
| +--------+ |
| | ^ |
| 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | |
| 2,4| |
| v |
+--------+ 7 +--------+ |
| |------>| |----------+
| Deg | | Up |
| |<------| |
+--------+ 8 +--------+
| ^
| |
+--+
2,3,4,5,6
Figure 4: LMP TE Link FSM
In the above FSM, the sub-states that may be implemented when the
link verification procedure is used have been omitted.
BM> Consider a TE Link that transitions to Down state via Degraded.. it
BM> has no data links and no CCs either. If now a DC is added to the TE
BM> Link, shouldn't it go [back] to degraded state, rather than Init.
BM> When a TE Link in the Down state gets a new data link, it fits
BM> the definition of the degraded state.
[Jonathan]no. Degraded applies only when data links are allocated to data
traffic.
<snip>
13.
LMP Message Formats
All LMP messages are IP encoded (except, in some cases, the Test
messages are limited by the transport mechanism for in-band
messaging) with protocol number xxx - TBA (to be assigned) by IANA.
13.1.
Common Header
In addition to the standard IP header, all LMP messages (except, in
some cases, the Test messages which are limited by the transport
mechanism for in-band messaging) have the following common header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers: 4 bits
Protocol version number. This is version 1.
Flags: 8 bits. The following values are defined. All other values
are reserved.
0x01: ControlChannelDown
0x02: LMP Restart
This bit is set to indicate the LMP component has
restarted. This flag may be reset to 0 when a Hello
message is received with RcvSeqNum equal to the local
TxSeqNum.
0x04: LMP-WDM Support
When set, indicates that this node is willing and
capable of receiving all the messages and objects
described in [LMP-DWDM].
0x08: Authentication
When set, this bit indicates that an authentication
block is attached at the end of the LMP message. See
Sections 7 and 9.3 for more details.
Msg Type: 8 bits. The following values are defined. All other
values are reserved.
1 = Config
2 = ConfigAck
3 = ConfigNack
4 = Hello
5 = BeginVerify
6 = BeginVerifyAck
7 = BeginVerifyNack
8 = EndVerify
9 = EndVerifyAck
10 = Test
11 = TestStatusSuccess
12 = TestStatusFailure
13 = TestStatusAck
14 = LinkSummary
15 = LinkSummaryAck
16 = LinkSummaryNack
17 = ChannelStatus
18 = ChannelStatusAck
19 = ChannelStatusRequest
20 = ChannelStatusResponse
All of the messages are sent over the control channel EXCEPT
the Test message, which is sent over the data link that is
being tested.
LMP Length: 16 bits
The total length of this LMP message in bytes, including the
common header and any variable-length objects that follow.
Checksum: 16 bits
The standard IP checksum of the entire contents of the LMP
message, starting with the LMP message header. This checksum is
calculated as the 16-bit one's complement of the one's
complement sum of all the 16-bit words in the packet. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before calculating the
checksum.
BM> One thing that will be of great help for implementation is a "message
BM> specific" field (perhaps a couple of them). An example use of such a
field
BM> could be to store the number of data link objects in a link summary
BM> and link summary ack message.
<snip>
13.4.
Parameter Negotiation Messages
BM> Suggest changing to "Hello parameter negotiation messages".
[Jonathan]I'd rather not. Currently all that is exchanged in Config is
Hello parameters, but this may not always be the case.
13.4.1. Config Message (MsgType = 1)
The Config message is used in the control channel negotiation phase
of LMP. The contents of the Config message are built using LMP
objects. The format of the Config message is as follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
BM> If order is to be followed for ALL messages, include it in one
BM> place at beginning of section 13
[Jonathan]Since these are objects, they may come in any order. However
Common Header must the first thing in an Lmp frame.
The MESSAGE_ID is within the scope of the CCID.
The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a timeout expires
and no ConfigAck or ConfigNack message has been received, or (3) it
receives a Config message from the remote node and has lost the
contention (e.g., the Node Id of the remote node is higher than the
Node Id of the local node). Both the retransmission interval and
the timeout period are local configuration parameters.
<snip>
13.5.
Hello Message (MsgType = 4)
The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <Hello>
BM> ^^^^^^ Should be in
upper case
[Jonathan]thanks.
<snip>
13.7.3. LinkSummaryNack Message (MsgType = 16)
The LinkSummaryNack message is used to indicate disagreement on non-
negotiated parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be
included in the LinkSummaryNack Object.
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
The LinkSummary TLVs MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes LinkSummary
TLVs for non-negotiable parameters, they MUST be copied from the
LinkSummary TLVs received in the LinkSummary message.
If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be
sent. The values received in the new LinkSummary message SHOULD
take into account the acceptable parameters included in the
LinkSummaryNack message.
BM> It looks like sending a linksummarynack that includes both
non-negotiable
BM> parameters as well as negotiable parameters is kind of useless..
BM> because the initiator will not resend a link summary in that case. Yes?
[Jonathan]It provides information as to why the link will not be brought up.
This can be used to correct a misconfiguration.
<snip>
14.
LMP Object Definitions
14.1.
CCID (Control Channel ID) Classes
14.1.1. LOCAL_CCID Class
Class = 1.
o C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits
This MUST be node-wide unique and non-zero. The CC_Id
identifies the control channel of the sender associated with
the message.
This Object is non-negotiable.
BM> Suggestion: Why not reserve C-Type = 2 for OIF- OIF OUNI 125.7 allows
BM> CCID to be either numbered (IPv4) or unnumbered.
[Jonathan]The CCId is defined as a 32-bit number. Both IPv4 and unnumbered
fit into this case. I don't think any distinction is needed in this case.
<snip>
14.7.
CONFIG Class
Class = 11.
o HelloConfig, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms).
HelloDeadInterval: 16 bits.
If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The
HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval.
If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero.
BM> Given that the only parameters negotiated by Hello COnfig are
BM> these two parameters, if fast keep-alive mechanism is not used,
BM> why bother with Hello Config protocol? Why then say Hello Config
BM> is mandatory?
[Jonathan]The Config message can still be used to indicate that Hellos will
not be used.
<snip>
14.16. ERROR_CODE Class
Class = 20.
o CONFIG_ERROR, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined:
0x01 = Unacceptable non-negotiable CONFIG parameter
0x02 = Renegotiate CONFIG parameter
0x04 = Bad Received CCID
All other values are Reserved.
Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable.
BM> How about adding a bit for "Ill-formed message" to cover
BM> such cases as object-order-violations?
BM> THese could be under a special C-Type, say, PROTOCOL_ERROR
Good idea about a PROTOCOL_ERROR C-Type. As a side note, object order is a
SHOULD, so violations must not result in an ERROR.