RFC 8532
Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
Pages: 59
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 44 to 59
6. Connectionless Model Applicability
The "ietf-connectionless-oam" module defined in this document provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. This module can be further extended to include technology-specific details, e.g., adding new data nodes with technology-specific functions and parameters into proper anchor points of the base model, so as to develop a technology-specific connectionless OAM model. This section demonstrates the usability of the connectionless YANG OAM data model to various connectionless OAM technologies, e.g., BFD and LSP ping. Note that, in this section, several snippets of technology-specific model extensions are presented for illustrative purposes. The complete model extensions should be worked on in the working groups of the respective protocols.
6.1. BFD Extension
RFC 7276 defines BFD as a connection-oriented protocol. It is used to monitor a connectionless protocol in the case of basic BFD for IP.6.1.1. Augment Method
The following sections show how the "ietf-connectionless-oam" module can be extended to cover BFD technology. For this purpose, a set of extensions are introduced such as the technology-type extension and test-point attributes extension. Note that a dedicated BFD YANG data model [BFD-YANG] is also standardized. Augmentation of the "ietf-connectionless-oam" module with BFD-specific details provides an alternative approach with a unified view of management information across various OAM protocols. The BFD-specific details can be the grouping defined in the BFD model, thereby avoiding duplication of effort.6.1.1.1. Technology-Type Extension
No BFD technology type has been defined in the "ietf-connectionless- oam" module. Therefore, a technology-type extension is required in the module extension. The snippet below depicts an example of adding the "bfd" type as an augment to the "ietf-connectionless-oam" module: augment "/nd:networks/nd:network/nd:node/" +"coam:location-type/coam:ipv4-location-type" +"/coam:test-point-ipv4-location-list/" +"coam:test-point-locations/coam:technology" { leaf bfd{ type string; } }6.1.1.2. Test Point Attributes Extension
To support BFD, the "ietf-connectionless-oam" module can be extended by adding specific parameters into the "test-point-locations" list and/or adding a new location type such as "BFD over MPLS TE" under "location-type".
6.1.1.2.1. Define and Insert New Nodes into Corresponding test-point- location
In the "ietf-connectionless-oam" module, multiple "test-point- location" lists are defined under the "location-type" choice node. Therefore, to derive a model for some BFD technologies (such as IP single-hop, IP multihop, etc.), data nodes for BFD-specific details need to be added to the corresponding "test-point-locations" list. In this section, some groupings that are defined in [BFD-YANG] are reused as follows. The snippet below shows how the "ietf-connectionless-oam" module can be extended to support "BFD IP Single-Hop": augment "/nd:networks/nd:network/nd:node/" +"coam:location-type/coam:ipv4-location-type" +"/coam:test-point-ipv4-location-list/" +"coam:test-point-locations" { container session-cfg { description "BFD IP single-hop session configuration"; list sessions { key "interface dest-addr"; description "List of IP single-hop sessions"; leaf interface { type if:interface-ref; description "Interface on which the BFD session is running."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer"; } uses bfd:bfd-grouping-common-cfg-parms; uses bfd:bfd-grouping-echo-cfg-parms; } } } Similar augmentations can be defined to support other BFD technologies such as BFD IP Multihop, BFD over MPLS, etc.
6.1.1.2.2. Add New location-type Cases
In the "ietf-connectionless-oam" module, If there is no appropriate "location-type" case that can be extended, a new "location-type" case can be defined and inserted into the "location-type" choice node. Therefore, there is flexibility -- the module user can add "location- type" to support other types of test point that are not defined in the "ietf-connectionless-oam" module. In this section, a new "location-type" case is added, and some groupings that are defined in [BFD-YANG] are reused as follows. The snippet below shows how the "ietf-connectionless-oam" module can be extended to support "BFD over MPLS-TE": augment "/nd:networks/nd:network/nd:node/coam:location-type"{ case te-location{ list test-point-location-list{ key "tunnel-name"; leaf tunnel-name{ type leafref{ path "/te:te/te:tunnels/te:tunnel/te:name"; } description "Point to a TE instance."; } uses bfd:bfd-grouping-common-cfg-parms; uses bfd-mpls:bfd-encap-cfg; } } } Similar augmentations can be defined to support other BFD technologies such as BFD over LAG, etc.6.1.2. Schema Mount
An alternative method is using the schema mount mechanism [RFC8528] in the "ietf-connectionless-oam" module. Within the "test-point- locations" list, a "root" attribute is defined to provide a mount point for models that will be added onto per "test-point-locations". Therefore, the "ietf-connectionless-oam" module can provide a place in the node hierarchy where other OAM YANG data models can be attached, without any special extension in the "ietf-connectionless- oam" YANG data module [RFC8528]. Note that the limitation of the schema mount method is that it's not allowed to specify certain modules that are required to be mounted under a mount point.
The snippet below depicts the definition of the "root" attribute.
anydata root {
yangmnt:mount-point root;
description
"Root for models that are supported per test point";
}
The following section shows how the "ietf-connectionless-oam" module
can use schema mount to support BFD technology.
6.1.2.1. BFD Modules Might Be Populated in schema-mounts
To support BFD technology, "ietf-bfd-ip-sh" and "ietf-bfd-ip-mh" YANG
modules might be populated in the "schema-mounts" container:
<schema-mounts
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point>
<module> ietf-connectionless-oam </module>
<name>root</name>
<use-schema>
<name>root</name>
</use-schema>
</mount-point>
<schema>
<name>root</name>
<module>
<name>ietf-bfd-ip-sh </name>
<revision>2016-07-04</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-bfd-ip-mh</name>
<revision> 2016-07-04</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh
</namespace>
<conformance-type>implement</conformance-type>
</module>
</schema>
</schema-mounts>
and the "ietf-connectionless-oam" module might have:
<ietf-connectionless-oam
uri="urn:ietf:params:xml:ns:yang:ietf-connectionless-oam">
......
<test-point-locations>
<ipv4-location>192.0.2.1</ipv4-location>
......
<root>
<ietf-bfd-ip-sh uri="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<ip-sh>
foo
......
</ip-sh>
</ietf-bfd-ip-sh>
<ietf-bfd-ip-mh uri="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh">
<ip-mh>
foo
......
</ip-mh>
</ietf-bfd-ip-mh>
</root>
</test-point-locations>
</ietf-connectionless-oam>
6.2. LSP Ping Extension
6.2.1. Augment Method
The following sections show how the "ietf-connectionless-oam" module
can be extended to support LSP ping technology. For this purpose, a
set of extensions are introduced such as the "technology-type"
extension and the test-point "attributes" extension.
Note that an LSP Ping YANG data model is being specified
[LSP-PING-YANG]. As with BFD, users can choose to use the
"ietf-connectionless-oam" as the basis and augment the
"ietf-connectionless-oam" model with details specific to LSP Ping in
the model extension to provide a unified view across different
technologies. The details that are specific to LSP Ping can be the
grouping defined in the LSP ping model to avoid duplication of
effort.
6.2.1.1. Technology-Type Extension
No LSP Ping technology type has been defined in the
"ietf-connectionless-oam" module. Therefore, a technology-type
extension is required in the module extension.
The snippet below depicts an example of augmenting
"ietf-connectionless-oam" with "lsp-ping" type:
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations/coam:technology"
{
leaf lsp-ping{
type string;
}
}
6.2.1.2. Test Point Attributes Extension
To support LSP Ping, the "ietf-connectionless-oam" module can be
extended and parameters specific to LSP Ping can be defined and put
on the "test-point-locations" list.
Users can reuse the attributes or groupings that are defined in
[LSP-PING-YANG] as follows:
The snippet below depicts an example of augmenting the "test-point-
locations" list with LSP Ping attributes:
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations"
{
list lsp-ping {
key "lsp-ping-name";
leaf lsp-ping-name {
type string {
length "1..31";
}
mandatory "true";
description "LSP Ping test name.";
......
}
6.2.2. Schema Mount
An alternative method is using the schema mount mechanism [RFC8528]
in the "ietf-connectionless-oam" module. Within the "test-point-
locations" list, a "root" attribute is defined to provide a mounted
point for models mounted per "test-point-locations". Therefore, the
"ietf-connectionless-oam" model can provide a place in the node
hierarchy where other OAM YANG data models can be attached, without any special extension in the "ietf-connectionless-oam" YANG data module [RFC8528]. Note that the limitation of the schema mount method is that it's not allowed to specify certain modules that are required to be mounted under a mount point. The snippet below depicts the definition of "root" attribute. anydata root { yangmnt:mount-point root; description "Root for models supported per test point"; } The following section shows how the "ietf-connectionless-oam" module can use schema mount to support LSP Ping technology.6.2.2.1. LSP Ping Modules Might Be Populated in schema-mounts
To support LSP Ping technology, the "ietf-lsp-ping" YANG module [LSP-PING-YANG] might be populated in the "schema-mounts" container: <schema-mounts xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"> <mount-point> <module> ietf-connectionless-oam </module> <name>root</name> <use-schema> <name>root</name> </use-schema> </mount-point> <schema> <name>root</name> <module> <name>ietf-lsp-ping </name> <revision>2016-03-18</revision> <namespace> urn:ietf:params:xml:ns:yang: ietf-lsp-ping </namespace> <conformance-type>implement</conformance-type> </module> </schema> </schema-mounts>
and the "ietf-connectionless-oam" module might have:
<ietf-connectionless-oam
uri="urn:ietf:params:xml:ns:yang:ietf-connectionless-oam">
......
<test-point-locations>
<ipv4-location> 192.0.2.1</ipv4-location>
......
<root>
<ietf-lsp-ping uri="urn:ietf:params:xml:ns:yang:ietf-lsp-ping">
<lsp-pings>
foo
......
</lsp-pings>
</ietf-lsp-ping>
</root>
</test-point-locations>
</ietf-connectionless-oam>
7. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The NETCONF Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive in some
network environments. Write operations (e.g., edit-config) to these
data nodes without proper protection can have a negative effect on
network operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:
/nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:ipv4-
location-type/cl-oam:test-point-ipv4-location-list/cl-oam:test-
point-locations/
/nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:ipv6-
location-type/cl-oam:test-point-ipv6-location-list/cl-oam:test-
point-locations/
/nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:mac-
location-type/cl-oam:test-point-mac-address-location-list/cl-
oam:test-point-locations/
/nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:group-
as-number-location-type/cl-oam:test-point-as-number-location-list/
cl-oam:test-point-locations/
/nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:group-
router-id-location-type/cl-oam:test-point-system-info-location-
list/cl-oam:test-point-locations/
Unauthorized access to any of these lists can adversely affect OAM
management system handling of end-to-end OAM and coordination of OAM
within underlying network layers. This may lead to inconsistent
configuration, reporting, and presentation for the OAM mechanisms
used to manage the network.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
/coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-count/
/coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-up-count/
/coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-down-count/
/coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-admin-down-
count/
/coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-count/
/coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-up-count//
/coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-down-count/
/coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-
statistics/cl-oam:cc-session-statistics/cl-oam:session-admin-down-
count/
8. IANA Considerations
This document registers URIs in the "IETF XML Registry" [RFC3688].
Following the format in [RFC3688], the following registrations have
been made.
URI: urn:ietf:params:xml:ns:yang:ietf-lime-time-types
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers two YANG modules in the "YANG Module Names"
registry [RFC6020].
Name: ietf-lime-time-types
Namespace: urn:ietf:params:xml:ns:yang:ietf-lime-time-types
Prefix: lime
Reference: RFC 8532
Name: ietf-connectionless-oam
Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
Prefix: cl-oam
Reference: RFC 8532
9. References
9.1. Normative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, DOI 10.17487/RFC1831,
August 1995, <https://www.rfc-editor.org/info/rfc1831>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4382] Nadeau, T., Ed. and H. van der Linde, Ed., "MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base", RFC 4382, DOI 10.17487/RFC4382, February 2006, <https://www.rfc-editor.org/info/rfc4382>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>. [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, <https://www.rfc-editor.org/info/rfc8529>.9.2. Informative References
[BFD-YANG] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Work in Progress, draft-ietf-bfd-yang- 17, August 2018. [G.800] "Unified functional architecture of transport networks", ITU-T Recommendation G.800, 2016.
[G.8013] "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, 2013. [IEEE.1588v1] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 1", IEEE Std 1588, 2002. [IEEE.1588v2] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", IEEE Std 1588, 2008. [LSP-PING-YANG] Zheng, L., Zheng, G., Mirsky, G., Rahman, R., and F. Iqbal, "YANG Data Model for LSP-Ping", Work in Progress, draft-zheng-mpls-lsp-ping-yang-cfg-10, January 2019. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, DOI 10.17487/RFC6136, March 2011, <https://www.rfc-editor.org/info/rfc6136>. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>. [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.
[RFC8531] Kumar, D., Wu, Q., and M. Wang, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019, <https://www.rfc-editor.org/info/rfc8531>. [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, " A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8533, DOI 10.17487/RFC8533, April 2019.Acknowledgments
The authors of this document would like to thank Elwyn Davies, Alia Atlas, Brian E. Carpenter, Greg Mirsky, Adam Roach, Alissa Cooper, Eric Rescorla, Ben Campbell, Benoit Claise, Kathleen Moriarty, Carlos Pignataro, and others for their substantive review and comments, and proposals to stabilize and improve the document.
Authors' Addresses
Deepak Kumar CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035 United States of America Email: dekumar@cisco.com Michael Wang Huawei Technologies, Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China Email: wangzitao@huawei.com Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Reshad Rahman Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: rrahman@cisco.com Srihari Raghavan Cisco Systems Tril Infopark Sez, Ramanujan IT City Neville Block, 2nd floor, Old Mahabalipuram Road Chennai, Tamil Nadu 600113 India Email: srihari@cisco.com