Internet DRAFT - draft-pelletier-mpls-ldp-bindings-refresh
draft-pelletier-mpls-ldp-bindings-refresh
MPLS Working Group Andre Pelletier
Internet Draft Kamran Raza
Intended status: Standards Track
Expires: August 24, 2013 Cisco Systems, Inc.
February 25, 2013
LDP Bindings Refresh
draft-pelletier-mpls-ldp-bindings-refresh-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
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
This Internet-Draft will expire on August 24, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Pelletier, et. al Expires August 2013 [Page 1]
Internet-Draft LDP Bindings Refresh February 2013
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
There are situations when there is a need for performing consistency
checks for LDP binding state (address/label bindings) exchanged
between LDP speakers. For instance, a state refresh may be required
to detect and purge stale bindings received by an LDP speaker, which
have resulted from an in-service software upgrade. This document
specifies mechanics that allow a sender LDP speaker to enclose the
initial binding advertisements (or re-advertisements) between
explicit START and END of binding markers, thus helping the
receiving LDP speaker to detect and purge any extra/stale binding
state previously learnt from the sender. In addition to the
definition of new LDP Notification message status codes for bindings
refresh, this document also extends LDP base specification by
introducing the concept of "Wildcard Address" and a new "Wildcard
Address Request" message.
Table of Contents
1. Introduction .....................................................3
2. Conventions used in this document ................................4
2.1. External Dependencies ........................................4
3. Bindings Refresh Procedures ......................................4
3.1. LDP Bindings .................................................4
3.2. Triggers: Solicited and Unsolicited...........................5
3.3. Operation ....................................................5
3.3.1. START/END Marker Rules ...................................6
3.3.2. Solicited "Wildcard" Requests ............................7
4. Bindings Refresh Signaling .......................................8
4.1. "Bindings Refresh" Capability ................................8
4.2. Label Bindings Refresh .......................................9
4.2.1. Label START Marker ......................................10
4.2.2. Label END Marker ........................................10
4.3. Address Bindings Refresh ....................................10
4.3.1. "Wildcard Address" in an "Address List" TLV .............10
4.3.2. "Wildcard Address Request" message ......................11
4.3.3. Address START Marker ....................................12
4.3.4. Address END Marker ......................................13
5. Operational Examples ............................................13
5.1. Basic Use ...................................................13
5.2. Background Refresh ..........................................14
6. Security Considerations .........................................14
Pelletier, et. al Expires August 2013 [Page 2]
Internet-Draft LDP Bindings Refresh February 2013
7. IANA Considerations .............................................14
8. References ......................................................15
8.1. Normative References ........................................15
8.2. Informative References..... .................................15
9. Acknowledgments .................................................15
1. Introduction
There are an increasing number of applications that are being
multiplexed over a single shared LDP session, each advertising a
distinct set of bindings. These applications may be introduced,
removed, or encounter a fault during the extended life of the
underlying LDP session. In these situations, it would be useful to
have an in-service state refresh mechanism to correct discrepancies
that may exist between the LDP speakers.
There are scenarios for established LDP sessions where it would be
useful for an LDP speaker to know when its peer has begun re-
advertisement of all labels and/or addresses, and when this re-
advertisement has completed. This delineation would allow the
receiver to perform a consistency check and an in-service state
reconcile, in a non-service-impacting manner.
For example, if a discrepancy exists between the advertised state of
an LDP speaker, versus the same state cached on a peer LSR,
currently, the only means of performing a complete reconcile is to
either flap the session, or withdrawal and replay of all state. This
re-advertisement or flap can adversely affect the network, and
trigger second order failures.
The LDP specification [RFC5036] provides no mechanism for an LDP
speaker to notify a peer LSR when it has begun an unsolicited (re-)
advertisement of all labels or address bindings to a peer. This
document specifies the use of START and END markers to clearly mark
the start and end of binding updates. This, in turn, helps the
receiving LSR to perform a hitless, in-service mark-and-sweep state
reconcile. The label binding markers, defined in this document,
complement and reuse the "End-of-LIB" notification and its
procedures defined in [RFC5919].
The binding refresh procedures specified in this document introduce
new LDP capability in accordance with LDP Capability framework
[RFC5561], a new LDP status code, and optional parameters in an LDP
Notification message.
Pelletier, et. al Expires August 2013 [Page 3]
Internet-Draft LDP Bindings Refresh February 2013
To provide a complete refresh and consistency check solution for
both sender-driven and receiver-driven LDP speakers, this document
allows solicited requests of label and/or address binding referesh.
To solicit address bindings, this document also extends LDP base
specification [RFC5036] by defining a "Wildcard Address" in an
Address List TLV and a new "Wildcard Address Request" LDP message.
2. Conventions used in this document
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 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the term "binding", when used unqualified, refers
to both LDP label and address binding. The term "START marker", when
used unqualified, refers to a notification delimiting the start of
label or address advertisement. Likewise, the term "END marker"
refers to a notification delimiting the completion of address or
label advertisement.
2.1. External Dependencies
Implementation of this draft is dependent on the following
specifications defined outside this document:
. The use of Typed Wildcard FEC Element [RFC5918] mandates that
firstly LDP "Typed Wildcard FEC" capability be successfully
negotiated between LDP peers before label binding markers can
be exchanged.
. This specification also updates the End-of-LIB notification
format as originally defined in RFC5919.
3. Bindings Refresh Procedures
To facilitate the description in the following sections, let us
consider two LDP speakers R1 and R2 with an LDP session between
them.
3.1. LDP Bindings
The state exchanged on an established LDP session between LDP peers
mainly consists of two types of bindings [RFC5036]:
Pelletier, et. al Expires August 2013 [Page 4]
Internet-Draft LDP Bindings Refresh February 2013
1. Label bindings: FEC to Label Mappings
2. Address bindings: IP addresses of local interfaces
Typically, LDP bindings are associated with an address family, and
are advertised and withdrawn using their specific mapping and
withdraw LDP messages. As per procedures and messages defined in RFC
5036 and RFC 5918, label bindings can also be solicited (requested).
3.2. Triggers: Solicited and Unsolicited
Loss or errors in tracking of advertised state within the
advertising or receiving LDP speaker can result in indefinite
retention of stale and potentially damaging state in the receiver
LSR. The root cause of these inconsistencies is outside the scope of
this document, but may include:
o In-service software upgrades
o Protocol process failures and restarts
o Stateful switchovers
o Software defects
In such scenarios, a software or end-user trigger may initiate a
state refresh between the peers for reconciling for both Label and
Address bindings.
Upon some trigger event, speaker R1 may perform an "unsolicited"
outbound state reconcile with peer R2 by pushing all bindings of a
given type to R2. Similarly, R2 may request a "solicited" state
reconcile from R1 by requesting R1 to replay all bindings of a given
type.
It is to be noted that while an LSR can use "Label Request" message
to solicit Label binding(s), LDP specification [RFC5036] contains no
provision to request address bindings from a LDP peer. This document
introduces a new LDP message, "Wildcard Address Request" message,
for soliciting addresses from an LDP peer.
3.3. Operation
LDP speakers that are capable of performing a binding refresh, as
specified in this document, first exchange "Binding Refresh" LDP
capability (Section 4.1). After successful negotiation of this
capability, both LDP speakers MUST respond as specified when
receiving messages defined in this specification.
Pelletier, et. al Expires August 2013 [Page 5]
Internet-Draft LDP Bindings Refresh February 2013
An LDP speaker SHOULD provide a user interface to an LSR
administrator to trigger an unsolicited binding refresh/re-
advertisement towards a peer or set of peers. A similar user
interface SHOULD be provided to solicit bindings refresh from a peer
or set of peers.
When advertising (or re-advertising) all its bindings, whether for
solicited or unsolicited reasons, an LDP speaker performs the
following sequence for a given binding type:
o Transmit a START marker identifying the given binding type;
o Advertise all bindings for given type;
o Transmit an END marker identifying the given binding type.
After END marker is received, the receiving LDP speaker MUST purge
any previously received bindings that were not re-advertised within
the START/END marker boundaries.
Although this specification defines the START/END markers to enclose
bindings advertisement, the specification does not restrict or limit
other RFC5036 messaging from occurring during this advertisement
period. For example, an LDP speaker may be re-advertising all its
label bindings for a certain FEC type as a low-priority background
reconcile task, but continues to advertise or withdraw addresses or
other FEC type bindings during this time.
NOTE: As a conformance test, if the START and END markers were to be
replaced by NO-OPs, the remaining sequence of advertisements and
withdrawals must continue to conform to RFC5036.
3.3.1. START/END Marker Rules
3.3.1.1. Sender Rules
o When advertising all bindings of a given type, the associated
START/END markers MUST bind the entire set of bindings of given
type.
o There is no ordering restriction between START and/or END markers
of different binding types.
Pelletier, et. al Expires August 2013 [Page 6]
Internet-Draft LDP Bindings Refresh February 2013
o If an LDP speaker is currently performing unsolicited
advertisement of bindings, and receives a solicited wildcard
request from the peer LDP speaker for the same binding type, then
it must abort the current refresh, and must restart the re-
advertisement from the beginning -- i.e. START marker, followed
by all bindings of the requested type, followed by END marker.
o An LDP speaker may restart a binding refresh by sending another
START marker of the same type, and then re-advertising the
bindings from the beginning, followed by the associated END
marker -- e.g. a user may interrupt a background refresh by
manually requesting another refresh of the same type.
3.3.1.2. Receiver Rules
o Upon receiving a START marker, the receiver MUST flag all
associated bindings as STALE.
o Upon receiving an END marker, the receiver MUST purge any
associated bindings that were not refreshed.
o Any received START marker for a given binding type MUST be
considered by the receiver to supersede any previously received
START marker of the same type.
o Any END marker for a given binding type MUST be considered by the
receiver to be paired with the most recently received START
marker of the same type.
3.3.2. Solicited "Wildcard" Requests
Upon receiving a Wildcard Label Request or Wildcard Address Request
from a peer with "Bindings Refresh" capability already negotiated
successfully, an LDP speaker:
o MAY send a START marker prior to responding with the requested
bindings. Returning a START marker is OPTIONAL, as the requesting
LSR is able to infer that the request itself is equivalent to a
START marker; all requested bindings will implicitly follow the
request event.
o MUST signal completion of the response by sending an END marker.
When sending an END marker in response to a Wildcard Request, the
END marker notification message MUST contain the "Message ID" TLV
of the associated Wildcard request. This ensures that the receiver
is able to correlate the END marker back to the associated wildcard
Pelletier, et. al Expires August 2013 [Page 7]
Internet-Draft LDP Bindings Refresh February 2013
request, as opposed to some unrelated END sent as part of an
unsolicited re-advertisement. This additional "Message ID" TLV is
placed under the "Optional Parameters" section of an LDP
Notification message. This specification, thus, also updates the
End-of-LIB notification format as originally defined in RFC5919.
The requesting LDP speaker MAY assume that any bindings that were
not returned between the request and the END marker containing the
associated message ID TLV response are stale, and may be purged.
If an LDP speaker has dispatched a solicited Wildcard Request for a
given binding type, and subsequently receives an END marker for the
same binding type, the receiver MUST ensure the presence of the
"Message ID" TLV within the END marker notification in order to
perform a purge of stale entries. The receiver LDP speaker MUST
notify the sender by transmitting LDP Notification message with
"Missing Message Parameters" status code if no such TLV is found.
Conversely, if the LDP speaker has solicited a Wildcard request and
receives an unsolicited END marker for the same binding type
(containing no "Message ID" TLV), this marker must be discarded, and
the receiver MUST NOT perform any sweep of stale entries.
4. Bindings Refresh Signaling
4.1. "Bindings Refresh" Capability
"Bindings Refresh" capability is a new LDP capability, defined in
accordance with LDP Capability definition guidelines [RFC5561].
An LDP speaker advertises "Bindings Refresh" capability to announce
to its peer its capability of supporting consistency check
procedures specified in this document. This capability MAY be sent
either in an Initialization message at the session establishment
time, or in a Capability message dynamically during the lifetime of
a session (only if "Dynamic Announcement" capability [RFC5561] has
been successfully negotiated).
The format of this capability is as follows:
Pelletier, et. al Expires August 2013 [Page 8]
Internet-Draft LDP Bindings Refresh February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|Bindings Refresh Cap.(IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1 : "Binding Refresh Capability" TLV Format
Where:
U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of
LDP Capabilities [RFC5561].
Bindings Refresh Capability: TLV type (IANA assigned)
Length: The length (in octets) of TLV. The value of this field
MUST be 1 as there is no Capability-specific data [RFC5561]
that follows in the TLV
S-bit: The value of this field is set in accordance with [RFC5561].
MUST be 1 if used in LDP "Initialization" message. MAY be
set to 0 or 1 in dynamic "Capability" message to advertise or
withdraw the capability respectively.
An LDP speaker that has successfully advertised "Bindings Refresh"
capability MUST support all the following status codes and procedures
in LDP Notification message (as described in later sections):
1. Label START Marker ( Section 4.2.1 )
2. Label END Marker ( Section 4.2.2 )
3. Address START Marker ( Section 4.3.3 )
4. Address END Marker ( Section 4.3.4 )
5. "Wildcard Address Request" message ( Section 4.3.2 )
4.2. Label Bindings Refresh
An LDP speaker that has successfully negotiated the "Bindings
Refresh" capability with a peer signals the commencement and end of
its label (re-) advertisements to the peer by means of a
LDP Notification message as follows.
Pelletier, et. al Expires August 2013 [Page 9]
Internet-Draft LDP Bindings Refresh February 2013
4.2.1. Label START Marker
The label "START" marker marks the commencement of label (re-)
advertisement towards a peer. This marker is signaled to an LDP peer
through LDP Notification message with following constructs:
o A Status TLV (with TLV E- and F-bits set to zero) that carries a
"Start-of-LIB" Status Code.
o A FEC TLV with a single Typed Wildcard FEC Element [RFC5918] that
identifies the FEC type for the label bindings those are to
follow. In terms of Section 3.5.1 of RFC5036, this TLV is an
"Optional Parameter" of the LDP Notification message.
4.2.2. Label END Marker
The label "END" marker marks the end of label (re-) advertisement
towards a peer. This specification re-uses the "End-of-LIB"
notification defined in RFC5919 to implement this marker. Given that
this document already mandates the successful negotiation of
"Bindings Refresh" capability before using End-of-LIB notification,
the document does not further require/mandate additional negotiation
of "Unrecognized Notification" Capability with peer [RFC5919] for
End-of-LIB support.
In addition to marking the completion of initial label advertisement
procedure defined in RFC5919, this marker MUST also be sent upon
completion of an unsolicited re-advertisement, or upon completion of
solicited typed wildcard requests, of all label bindings of given
FEC type.
4.3. Address Bindings Refresh
An LDP speaker that has successfully negotiated the "Bindings
Refresh" capability with a peer signals the commencement and end of
its address (re-) advertisements to the peer by means of a
LDP Notification message as described in following subsections.
New constructs are first defined that are required to signal START
and END markers for address bindings.
4.3.1. "Wildcard Address" in an "Address List" TLV
RFC5036 defines "Address List TLV" (in Section 3.4.3) as mandatory
TLV for use in an "Address" or "Address Withdraw" message, but it
does not define any "Wildcard Address" that can be specified in this
TLV.
Pelletier, et. al Expires August 2013 [Page 10]
Internet-Draft LDP Bindings Refresh February 2013
In the context of this specification, we define a "Wildcard Address"
that is specified by an empty "Address List" TLV - i.e. the TLV
containing only the Address-family identifier, with no addresses in
it. When received in an address message, it must be treated as "All-
addresses" for the given Address-family type.
The "Wildcard Address" is to be used in "Wildcard Address Request"
message as defined later in the document. This specification,
however, does not limit the applicability of "Wildcard Address" and
allows it to be used in an Address Withdraw message as well.
4.3.2. "Wildcard Address Request" message
RFC5036 specifies mechanisms and messages to solicit label bindings
from peer using Label Request message, but does not define any
soliciting mechanisms for address bindings.
In this document, a new LDP message type "Wildcard Address Request"
is being defined. The format of Wildcard Address Request message is
as follows:
Pelletier, et. al Expires August 2013 [Page 11]
Internet-Draft LDP Bindings Refresh February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Wcrd Address Request(IANA) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 : "Wildcard Address Request" message format
Where:
U-bit: MUST be 0.
Message ID: 32-bit value used to identify this message [RFC5036].
Address List TLV: TLV and its encoding as specified in
[RFC5036]. This TLV MUST contain an empty address list (i.e.
"Wildcard Address" as defined in this document section 4.3.1.
Optional Parameters: No optional parameters are defined for the
Wildcard Address Request message.
Having negotiated "Bindings Refresh" capability, an LDP speaker MUST
respond to received "Wildcard Address Request" message by replaying
all its address bindings in one or more Address messages to the
requesting LSR. When an Address message contains address bindings
being sent as a response to incoming Wildcard Address Request
message, the Address message MUST contain the "Message ID" TLV
containing the message id of the request message.
4.3.3. Address START Marker
The Address "START" marker marks the commencement of address (re-)
advertisement towards a peer for given address family. This marker
is signaled to an LDP peer through an LDP Notification message with
the following constructs:
Pelletier, et. al Expires August 2013 [Page 12]
Internet-Draft LDP Bindings Refresh February 2013
o A status TLV (with TLV E- and F-bits set to zero) that carries a
"Start-of-Addresses" Status Code.
o A single "Address List" TLV with given address family and
"Wildcard Address". In terms of Section 3.5.1 of RFC5036, this
TLV is an "Optional Parameter" of the LDP Notification message.
4.3.4. Address END Marker
The Address "END" marker marks the end of address (re-)
advertisement towards a peer for a given address family. This marker
is signaled to an LDP peer through LDP Notification message with
following constructs:
o A status TLV (with TLV E- and F-bits set to zero) that carries a
"End-of-Addresses" Status Code.
o A single "Address List" TLV with given address family and
"Wildcard Address". In terms of Section 3.5.1 of RFC5036, this
TLV is an "Optional Parameter" of the LDP Notification message.
5. Operational Examples
5.1. Basic Use
A basic use-case would consist of:
Advertise X1
Advertise X2
Advertise X3
START (binding type X)
Advertise X1
Advertise X2
END (binding type X)
In the above sequence, the receiver would create database entries
upon initially receiving X1, X2 and X3.
Upon receiving the START marker, the receiver would flag all
previously received bindings of type X as stale. The re-
advertisement of bindings X1 and X2 would cause the receiver to flag
these database entries as refreshed.
Upon receiving the END marker, the receiver would purge binding X3,
as it was not refreshed.
Pelletier, et. al Expires August 2013 [Page 13]
Internet-Draft LDP Bindings Refresh February 2013
5.2. Background Refresh
In this example, a background binding refresh is interrupted by a
withdrawal, and advertisement of a new binding:
Advertise X1
Advertise X2
Advertise X3
START (binding type X)
Advertise X1
Advertise X2
>> Withdraw X1
Advertise X3
>> Advertise X4
END (binding type X)
In the above sequence, all bindings were refreshed, but binding X1
was withdrawn during the re-advertisement sequence, and another
binding X4 was introduced.
The final receiver database will contain only bindings X2, X3, and
X4. In this example, no further bindings were purged upon receiving
the END marker, and X1 was removed due to explicit withdrawal
request.
6. Security Considerations
This extension to LDP does not introduce any new security
considerations beyond that already apply to the base LDP
specification [RFC5036] and [RFC5920].
7. IANA Considerations
The document introduces following new protocol elements that require
code point assignment by IANA:
o "Bindings Refresh Capability" TLV (requested code point: 0x50F
from LDP registry "TLV Type Name Space")
o "Wildcard Address Request" message (requested code point: 0x302
from LDP registry "Message Type Name Space").
o New LDP status codes (requested code points as follows, to be
allocated from the LDP registry "Status Code Name Space"):
Pelletier, et. al Expires August 2013 [Page 14]
Internet-Draft LDP Bindings Refresh February 2013
Range/Value E Description
-------------- --- -----------------------------------------
0x00000031 0 Start-of-LIB
0x00000032 0 Start-of-Addresses
0x00000033 0 End-of-Addresses
8. References
8.1. Normative References
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
Thomas, B., "LDP Specification", RFC 5036, January 2001.
[RFC5919] R. Asati, P. Mohapatra, E. Chen, B. Thomas, "Signaling
LDP Label Advertisement Completion", RFC 5919,
August 2010.
[RFC5918] Asati, R., Minei, I., and Thomas, B. "Label Distribution
Protocol Typed Wildcard FEC", RFC 5918, August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and
JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
8.2. Informative References
[RFC5920] Fang, L. et al., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
9. Acknowledgments
The authors would like to acknowledge Eric Rosen for his review and
input on this specification.
This document was prepared using 2-Word-v2.0.template.dot.
Pelletier, et. al Expires August 2013 [Page 15]
Internet-Draft LDP Bindings Refresh February 2013
Authors' Addresses
Andre Pelletier
Cisco Systems, Inc.
2000 Innovation Drive,
Ottawa, Ontario K2K-3E8, Canada.
Email: apelleti@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive,
Ottawa, Ontario K2K-3E8, Canada.
Email: skraza@cisco.com
Pelletier, et. al Expires August 2013 [Page 16]
