[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Response to Your Questions about GMPLS Protocol Usage
Dear Lyndon,
Thanks for your communication dated 29th November 2007 and your subsequent
email exchange with clarifications.
Please find below responses from CCAMP experts to the questions you posed.
May we take this opportunity to stress that we are open to receiving such
questions in a less formal way either directly or through the CCAMP mailing
list, and may be able to provide timely responses during the course of your
testing events.
1) One of the features provided in the OIF UNI 2.0 is the ability to
non-disruptively modify service attributes associated with an LSP. The
modification of the service attributes is limited to LSPs that were
initiated using Shared Explicit filter style. Modification is performed
by signaling a new LSP that utilizes the same Tunnel ID as the original
LSP but with the new service parameters. Once the new LSP state is
established, the original LSP state is removed.
There are two distinct options for modifying an LSP. The first is
"in-place" modification where a new trigger Path message is sent for an
existing LSP. The second is the "make-before-break" approach to
tunnel/service modification first introduced in RFC 3209. You appear to be
referring to the latter case since you mention a new LSP.
Non-disruptive modification was demonstrated in the 2007
interoperability test by modifying the bandwidth of an LSP realized by a
SONET/SDH VCAT group. In the process of testing, a number of questions
arose regarding the RESV message flow. These questions included:
- How many RESV messages are expected to be generated? Is it one since
the resources in use by both LSPs are the same, or two since the LSPs
are handled through separate signaling sessions.
In make-before-break, each LSP is signaled independently. Per LSP Resv
messages should be expected. Assuming the old LSP is in-place at the time
of signaling the new LSP, and only one Path message is issued, then only one
Resv would be expected. That is, a Resv for the new LSP, but no further Resv
for the existing LSP.
When the old LSP is also modified as part of the make-before-break, e.g., to
update administrative status prior to alarm-free tear-down, then a Resv
message on the old LSP may also be generated.
- What is the bandwidth amount that should be reflected in the RESV
messages? If separate RESV messages are generated for both LSPs, is it
the bandwidth requested in the corresponding PATH message? Or is it
the actual bandwidth being provided by the connection at the time the
RESV message is generated?
According to RFC 4606:
For a particular sender in a session, the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the contents
of the SENDER_TSPEC object received in the corresponding Path
message. If the objects do not match, a ResvErr message with a
"Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
Again, in make-before-break, each LSP is signaled independently.
In the interop test both approaches were observed. To facilitate the
subsequent demonstration, receivers were expected to handle both cases.
2) In the process of testing, we found that not all implementations
included Explicit Route Objects (ERO) in PATH messages when performing
graceful deletion, even though earlier PATH messages for the LSP had
included an ERO. For some intermediate node implementations, the lack of
the ERO was seen as removing the 'pinned' nature of the connection,
causing the node to interpret the PATH message as requiring a new path
computation which may end up using a different route. Other
implementations utilized the Session and Sender Template to relate the
received PATH message with the existing connection thereby identifying
the path the message should be forwarded on. This approach was taken by
these implementations since inclusion of an ERO is not mandatory. We
would appreciate CCAMP's thoughts on what the behavior should be.
As described in RFC 2205, Path and Resv messages are idempotent. This means
that any Path message reflects full state, and differences between one Path
message and a subsequent Path message may be reasonably considered an
explicit change. Therefore, while there is no explicit requirement stated in
RFC 3473, it is typical to only modify the Admin Status Object in Path
messages sent in connection to RFC 3473 section 7.2.1. deletion procedures
(i.e. to include the full ERO as on previous Path messages).
It may be observed, however, that while an implementation detecting a change
in ERO (such as the removal of the ERO) may legitimately opt to reroute,
that implementation should also note the change in Admin Status associated
with the graceful deletion and may "assume" that such a reroute would be a
waste of time. Further, in a transport system, implementations should only
perform local reroutes (deviating from in-place LSPs) with extreme caution
since these risk impacting traffic.
3) In the process of testing, we found cases where the update of a
link's attributes (i.e. available capacity) was not being done by
advertising an updated LSA using the same LSAid, but by flushing the old
LSA followed by generation of a new LSA with a new LSAid. Since the
LSAid for Opaque LSAs is not tied to the resource being advertised
(i.e. the resource is identified using TLVs in the Opaque LSA, not using
the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as
it causes the order that the LSAs are processed to become important. We
would appreciate CCAMP's thoughts on what the behavior should be.
The OSPF WG, is the proper WG to respond to this as they are the
authoritative source on OSPF technology. From our perspective, RFC 2328
dictates the use of the same Link State ID when advertising a change in
information about a link, and RFC 3630 states "The LSA ID has no
topological significance."
While it is certainly possible to advertise a change via issuing an LSA with
a new Link State ID and flushing old state, from the perspective of OSPF
this is not a change in link state, rather a completely new link.
In fact, when there are key changes to the information advertised about a
link (for example, a change to the Link Type or Link ID), the advertising
router should recognise that these changes represent the advertisement of a
new link and should use a new LSA with a new Link State ID. However, where
the change is clearly a change to the link state of an existing link, the
advertising router should use the same Link State ID.
4) Finally, in the process of testing, we found cases where established
connections were deleted based on node restart procedures in RFC
3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006)
states deletion of established connections as the result of control
plane failure (including node restart) shall not occur. It has been
identified this could also occur when a number of cascaded nodes restart
at the same time. We would appreciate CCAMP's thoughts on ways to
prevent deletion of established connections from occurring when a node
restarts.
Without specific details, it's impossible to address the found cases or to
identify if they were due to implementation or specification issues.
More broadly, RFC 3473 does not require the removal of forwarding state,
even in the case of state synchronization errors, and implementations may
take different action (such as reporting the condition to a management
station). An implementation at a restarting node may consider that the lack
of control plane state at its (fully functional) neighbor indicates that the
removal of forwarding plane state has been attempted through the control
plane while the restarting node was down and should follow local policy in
determining how to react.
We would also like to direct you to RFC 5063 and
draft-ietf-ccamp-gr-description which may provide additional relevant
information.
We hope this addresses your questions.
Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs