draft-ietf-ospf-manet-single-hop-or-04.txt   rfc7137.txt 
Network Working Group A. Retana Internet Engineering Task Force (IETF) A. Retana
Internet-Draft S. Ratliff Request for Comments: 7137 S. Ratliff
Updates: 5820 (if approved) Cisco Systems, Inc. Updates: 5820 Cisco Systems, Inc.
Intended status: Experimental December 18, 2013 Category: Experimental February 2014
Expires: June 21, 2014 ISSN: 2070-1721
Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks
draft-ietf-ospf-manet-single-hop-or-04
Abstract Abstract
This document describes the use of the OSPF-MANET interface in This document describes the use of the OSPF-MANET interface in
single-hop broadcast networks. It includes a mechanism to single-hop broadcast networks. It includes a mechanism to
dynamically determine the presence of such a network and specific dynamically determine the presence of such a network and specific
operational considerations due to its nature. operational considerations due to its nature.
This document updates RFC5820. This document updates RFC 5820.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 21, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7137.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . 3 1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Single-Hop Network Operation . . . . . . . . . . . . . . . . 3 3. Single-Hop Network Operation . . . . . . . . . . . . . . . . 4
3.1. Use of Router Priority . . . . . . . . . . . . . . . . . 4 3.1. Use of Router Priority . . . . . . . . . . . . . . . . . 4
3.2. Unsynchronized Adjacencies . . . . . . . . . . . . . . . 5 3.2. Unsynchronized Adjacencies . . . . . . . . . . . . . . . 5
4. Single-Hop Network Detection . . . . . . . . . . . . . . . . 5 4. Single-Hop Network Detection . . . . . . . . . . . . . . . . 6
4.1. Transition from multi-hop to single-hop mode . . . . . . 6 4.1. Transition from Multi-Hop to Single-Hop Mode . . . . . . 6
4.2. Transition from single-hop to multi-hop mode . . . . . . 6 4.2. Transition from Single-Hop to Multi-Hop Mode . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8
A.1. Changes between the -00 and -01 versions. . . . . . . . . 8
A.2. Changes between the -01 and -02 versions. . . . . . . . . 8
A.3. Changes between the -02 and -03 versions. . . . . . . . . 8
A.4. Changes betwen the -03 and -04 versions . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The OSPF-MANET interface [RFC5820] uses the point-to-multipoint The OSPF-MANET interface [RFC5820] uses the point-to-multipoint
adjacency model over a broadcast media to allow the following: adjacency model over a broadcast media to allow the following:
o all router-to-router connections are treated as if they were o All router-to-router connections are treated as if they were
point-to-point links. point-to-point links.
o Link metric can be set on a per-neighbor basis. o The link metric can be set on a per-neighbor basis.
o Broadcast and multicast can be accomplished through the Layer 2 o Broadcast and multicast can be accomplished through the Layer 2
broadcast capabilities of the media. broadcast capabilities of the media.
It is clear that the characteristics of the MANET interface can also It is clear that the characteristics of the MANET interface can also
be beneficial in other types of network deployments; specifically in be beneficial in other types of network deployments -- specifically,
single-hop broadcast capable networks which may have a different cost in single-hop broadcast capable networks that may have a different
associated with any pair of nodes. cost associated with any pair of nodes.
This document updates [RFC5820] by describing the use of the MANET This document updates [RFC5820] by describing the use of the MANET
interface in single-hop broadcast networks, which consists of its interface in single-hop broadcast networks; this consists of its
simplified operation by not requiring the use of Overlapping Relays simplified operation by not requiring the use of overlapping relays
as well as introducing a new heuristic for Smart Peering using the as well as introducing a new heuristic for smart peering using the
Router Priority. Router Priority.
1.1. Single-Hop Broadcast Networks 1.1. Single-Hop Broadcast Networks
The OSPF extensions for MANET networks assume the ad-hoc formation of The OSPF extensions for MANETs assume the ad hoc formation of a
a network over bandwidth-constrained wireless links, where packets network over bandwidth-constrained wireless links, where packets may
may traverse several intermediate nodes before reaching their traverse several intermediate nodes before reaching their destination
destination (multi-hop paths on the interface). By contrast, a (multi-hop paths on the interface). By contrast, a single-hop
single-hop broadcast network (as considered in this document) is one broadcast network (as considered in this document) is one that is
that is structured in such a way that all the nodes in it are structured in such a way that all the nodes in it are directly
directly connected to each other. An Ethernet interface is a good connected to each other. An Ethernet interface is a good example of
example of the connectivity model. the connectivity model.
Furthermore, the single-hop networks considered may have different Furthermore, the single-hop networks considered may have different
link metrics associated to the connectivity between a specific pair link metrics associated to the connectivity between a specific pair
of neighbors. The OSPF broadcast model [RFC2328] can't accurately of neighbors. The OSPF broadcast model [RFC2328] can't accurately
describe these differences. A point-to-multipoint description is describe these differences. A point-to-multipoint description is
more appropriate given that each node can reach every other node more appropriate given that each node can reach every other node
directly. directly.
In summary, the single-hop broadcast interfaces considered in this In summary, the single-hop broadcast interfaces considered in this
document have the following characteristics: document have the following characteristics:
o direct connectivity between all the nodes o direct connectivity between all the nodes
o different link metrics may exist per-neighbor o different link metrics that may exist per-neighbor
o it has broadcast/multicast capabilities o broadcast/multicast capabilities
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Single-Hop Network Operation 3. Single-Hop Network Operation
The operation of the MANET interface doesn't change when implemented The operation of the MANET interface doesn't change when implemented
on a single-hop broadcast interface. However, the operation of some on a single-hop broadcast interface. However, the operation of some
of the proposed enhancements can be simplified. Explicitly, the of the proposed enhancements can be simplified. Explicitly, the
Overlapping Relay Discovery Process SHOULD NOT be executed and the Overlapping Relay Discovery Process SHOULD NOT be executed, and the
A-bit SHOULD NOT be set by any of the nodes: the result is an empty A-bit SHOULD NOT be set by any of the nodes, so that the result is an
set of Active Overlapping Relays. empty set of Active Overlapping Relays.
This document describes the use of already defined mechanisms and This document describes the use of already defined mechanisms and
requires no additional on-the-wire changes. requires no additional on-the-wire changes.
3.1. Use of Router Priority 3.1. Use of Router Priority
Smart Peering [RFC5820] can be used to reduce the burden of requiring Smart peering [RFC5820] can be used to reduce the burden of requiring
a full mesh of adjacencies. In short, a new adjacency is not a full mesh of adjacencies. In short, a new adjacency is not
required if reachability to the node is already available through the required if reachability to the node is already available through the
existing SPT. In general, the reachability is verified on a first- existing shortest path tree (SPT). In general, the reachability is
come-first-served basis; i.e. in a typical network, the neighbors verified on a first-come-first-served basis; i.e., in a typical
with which a FULL adjacency is set up depend on the order of network, the neighbors with which a FULL adjacency is set up depend
discovery. on the order of discovery.
The Smart Peering state machine allows for the definition of The state machine for smart peering allows for the definition of
heuristics, beyond the SPT reachability, to decide whether or not it heuristics, beyond the SPT reachability, to decide whether or not it
considers a new adjacency to be of value. This section describes one considers a new adjacency to be of value. This section describes one
such heuristic to be used in Step (3) of the state machine, in place such heuristic to be used in Step (3) of the state machine, in place
of the original one. of the original one in Section 3.5.3.2 of [RFC5820].
The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3 The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3
[RFC5340]) is used in the election of the (Backup) Designated Router, [RFC5340]) is used in the election of the (Backup) Designated Router,
and can be configured only in broadcast and NBMA interfaces. The and can be configured only in broadcast and Non-Broadcast Multi-
MANET interface is a broadcast interface using the point-to- Access (NBMA) interfaces. The MANET interface is a broadcast
multipoint adjacency model, which means that no (Backup) Designated interface using the point-to-multipoint adjacency model; this means
Router is elected. For its use with the MANET interface, the Router that no (Backup) Designated Router is elected. For its use with the
Priority is defined as: MANET interface, the Router Priority is defined as:
Router Priority Router Priority
An 8-bit unsigned integer. Used to determine the precedence of An 8-bit unsigned integer. Used to determine the precedence of
which router(s) to establish a FULL adjacency with during the which router(s) to establish a FULL adjacency with during the
Smart Peering selection process. When more than one router Smart Peering selection process. When more than one router
attached to a network is present, the one with the highest attached to a network is present, the one with the highest
Router Priority takes precedence. If there is still a tie, the Router Priority takes precedence. If there is still a tie, the
router with the highest Router ID takes precedence. router with the highest Router ID takes precedence.
The heuristic for the smart peering state machine is described as: The heuristic for the state machine for smart peering is described
as:
(3) | (3) |
,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''| ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
| ............................ | | ............................ |
| |Determine if the number of| | | |Determine if the number of| |
| |existing adjacencies is < | | | |existing adjacencies is < | |
| |the maximum configured | | | |the maximum configured | |
| |value | | | |value | |
| '`'''''''\'''''''''''''''/'' | | '`'''''''\'''''''''''''''/'' |
| \ / | | \ / |
| ................\.........../.............. | | ................\.........../.............. |
| |Determine if the neighbor has the highest| | | |Determine if the neighbor has the highest| |
| |(Router Priority, Router ID) combination | | | |(Router Priority, Router ID) combination | |
| ''''''''''''`'''/'''''''\'''''''''''''''''' | | ''''''''''''`'''/'''''''\'''''''''''''''''' |
| / \ | | / \ |
'`'''''''''''''''''''''/'''''''''''\''''''''''''''''''''''' '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
Smart Peering Algorithm Smart Peering Algorithm
In order to avoid churn in the selection and establishment of the In order to avoid churn in the selection and establishment of the
adjacencies, every router SHOULD wait until the ModeChange timer adjacencies, every router SHOULD wait until the ModeChange timer
(Section 4) expires before running the Smart Peering state machine. (Section 4) expires before running the state machine for smart
Note that this wait should cause the selection process to consider peering. Note that this wait should cause the selection process to
all the nodes on the link, instead of being triggered based on consider all the nodes on the link, instead of being triggered based
receiving a Hello message from a potential neighbor. The nodes on receiving a Hello message from a potential neighbor. The nodes
selected using this process are referred to simply as Smart Peers. selected using this process are referred to simply as "smart peers".
It is RECOMMENDED that the maximum number of adjacencies be set to 2. It is RECOMMENDED that the maximum number of adjacencies be set to 2.
3.2. Unsynchronized Adjacencies 3.2. Unsynchronized Adjacencies
An unsynchronized adjacency [RFC5820] is one for which the database An unsynchronized adjacency [RFC5820] is one for which the database
synchronization is postponed, but that is announced as FULL because synchronization is postponed, but that is announced as FULL because
SPT reachability can be proven. A single-hop broadcast network has a SPT reachability can be proven. A single-hop broadcast network has a
connectivity model in which all the nodes are directly connected to connectivity model in which all the nodes are directly connected to
each other. This connectivity results in a simplified reachability each other. This connectivity results in a simplified reachability
check through the SPT: the adjacency to a specific peer MUST be check through the SPT: the adjacency to a specific peer MUST be
advertized as FULL by at least one Smart Peer. advertised as FULL by at least one smart peer.
The single-hop nature of the interface allows then the advertisement The single-hop nature of the interface allows then the advertisement
of the reachable adjacencies as FULL without additional signaling. of the reachable adjacencies as FULL without additional signaling.
Flooding SHOULD be enabled for all the unsynchronized adjacencies to Flooding SHOULD be enabled for all the unsynchronized adjacencies to
take advantage of the broadcast nature of the media. As a result, take advantage of the broadcast nature of the media. As a result,
all the nodes in the interface will be able to use all the LSAs all the nodes in the interface will be able to use all the LSAs
received. received.
4. Single-Hop Network Detection 4. Single-Hop Network Detection
A single-hop network is one in which all the nodes are directly A single-hop network is one in which all the nodes are directly
connected. Detection of such an interface can be easily done at connected. Detection of such an interface can be easily done at
every node by comparing the speaker's 1-hop neighbors with its 2-hop every node by comparing the speaker's 1-hop neighbors with its 2-hop
neighborhood. If for every 1-hop neighbor, the set of 2-hop neighborhood. If for every 1-hop neighbor, the set of 2-hop
neighbors contains the whole set of the remaining 1-hop neighbors, neighbors contains the whole set of the remaining 1-hop neighbors,
then the interface is a single-hop network; this condition is called then the interface is a single-hop network; this condition is called
the Single-Hop Condition. the Single-Hop Condition.
A new field is introduced in the MANET interface data structure. The A new field is introduced in the MANET interface data structure. The
name of the field is SingleHop, and it is a flag indicating whether name of the field is SingleHop, and it is a flag indicating whether
skipping to change at page 6, line 17 skipping to change at page 6, line 20
neighborhood. If for every 1-hop neighbor, the set of 2-hop neighborhood. If for every 1-hop neighbor, the set of 2-hop
neighbors contains the whole set of the remaining 1-hop neighbors, neighbors contains the whole set of the remaining 1-hop neighbors,
then the interface is a single-hop network; this condition is called then the interface is a single-hop network; this condition is called
the Single-Hop Condition. the Single-Hop Condition.
A new field is introduced in the MANET interface data structure. The A new field is introduced in the MANET interface data structure. The
name of the field is SingleHop, and it is a flag indicating whether name of the field is SingleHop, and it is a flag indicating whether
the interface is operating in single-hop mode (as described in the interface is operating in single-hop mode (as described in
Section 3). The SingleHop flag is set when the node meets the Section 3). The SingleHop flag is set when the node meets the
Single-Hop Condition on the interface. If the Single-Hop Condition Single-Hop Condition on the interface. If the Single-Hop Condition
is no longer met then the SingleHop flag MUST be cleared. is no longer met, then the SingleHop flag MUST be cleared.
A new timer is introduced to guide the transition of the interface A new timer is introduced to guide the transition of the interface
from/to multi-hop mode (which is the default mode described in from/to multi-hop mode (which is the default mode described in
[RFC5820]) to/from single-hop mode: [RFC5820]) to/from single-hop mode:
o ModeChange: Every time a node changes the state of the SingleHop o ModeChange: Every time a node changes the state of the SingleHop
flag for the interface, the corresponding ModeChange timer MUST be flag for the interface, the corresponding ModeChange timer MUST be
set. The ModeChange timer represents the length of time in set. The ModeChange timer represents the length of time in
seconds that an interface SHOULD wait before changing between seconds that an interface SHOULD wait before changing between
multi-hop and single-hop modes. It is RECOMMENDED that this timer multi-hop and single-hop modes. It is RECOMMENDED that this timer
be set to Wait Time [RFC2328]. be set to Wait Time [RFC2328].
The following sections describe the steps to be taken to transition The following sections describe the steps to be taken to transition
between interface modes. between interface modes.
4.1. Transition from multi-hop to single-hop mode 4.1. Transition from Multi-Hop to Single-Hop Mode
Detection of the Single-Hop Condition triggers the transition into Detection of the Single-Hop Condition triggers the transition into
single-hop mode by setting both the SingleHop flag and the ModeChange single-hop mode by setting both the SingleHop flag and the ModeChange
timer. timer.
Once the ModeChange timer expires, the heuristic defined in Once the ModeChange timer expires, the heuristic defined in
Section 3.1 MAY be executed to optimize the set of adjacencies on the Section 3.1 MAY be executed to optimize the set of adjacencies on the
interface. Note that an adjacency MUST NOT transition from FULL to interface. Note that an adjacency MUST NOT transition from FULL to
2-Way unless the simplified reachabiity check (Section 3.2) can be 2-Way unless the simplified reachability check (Section 3.2) can be
verified. verified.
4.2. Transition from single-hop to multi-hop mode 4.2. Transition from Single-Hop to Multi-Hop Mode
Not meeting the Single-Hop Condition triggers the transition into Not meeting the Single-Hop Condition triggers the transition into
multi-hop mode by clearing the SingleHop flag and setting the multi-hop mode by clearing the SingleHop flag and setting the
ModeChange timer. The A-bit MUST be set if the Single-Hop condition ModeChange timer. The A-bit MUST be set if the Single-Hop condition
is no longer met because of one of the following cases: is no longer met because of one of the following cases:
o an increase in the set of 1-hop neighbors, without the o an increase in the set of 1-hop neighbors, without the
corresponding increase of the 2-hop neighborhood corresponding increase of the 2-hop neighborhood
o a decrease of the 2-hop neighborhood while maintaining all the o a decrease of the 2-hop neighborhood while maintaining all the
previous 1-hop neighbors previous 1-hop neighbors
Once the ModeChange timer expires, the multi-hop operation described Once the ModeChange timer expires, the multi-hop operation described
in [RFC5820] takes over. in [RFC5820] takes over.
Note that the cases listed above may result in the interface either Note that the cases listed above may result in the interface either
gaining or losing a node before the ModeChange timer expires. In gaining or losing a node before the ModeChange timer expires. In
both cases the heuristic defined in Section 3.1 MAY be executed to both cases, the heuristic defined in Section 3.1 MAY be executed to
optimize the set of adjacencies on the interface. optimize the set of adjacencies on the interface.
In the case that a node joins the interface, the Designated Router In the case that a node joins the interface, the Designated Router
and Backup Designated Router fields in the Hello packet [RFC2328] MAY and Backup Designated Router fields in the Hello packet [RFC2328] MAY
be used to inform the new node of the identity (Router ID) of the be used to inform the new node of the identity (Router ID) of the
current Smart Peers (and avoid the optimization). current smart peers (and avoid the optimization).
5. IANA Considerations
This document includes no request to IANA.
6. Security Considerations 5. Security Considerations
No new security concerns beyond the ones expressed in [RFC5820] are No new security concerns beyond the ones expressed in [RFC5820] are
introduced in this document. introduced in this document.
7. Acknowledgements 6. Acknowledgements
The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia
Atlas, Juan Antonio Cordero, Richard Ogier and Christer Holmberg for Atlas, Juan Antonio Cordero, Richard Ogier, and Christer Holmberg for
their comments. their comments.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5820] Roy, A. and M. Chandra, "Extensions to OSPF to Support [RFC5820] Roy, A. and M. Chandra, "Extensions to OSPF to Support
Mobile Ad Hoc Networking", RFC 5820, March 2010. Mobile Ad Hoc Networking", RFC 5820, March 2010.
8.2. Informative References 7.2. Informative References
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
Appendix A. Change Log
To be removed prior to publication.
A.1. Changes between the -00 and -01 versions.
o Updated contact information.
A.2. Changes between the -01 and -02 versions.
o Indicated the nature of the RFC5820 update.
o Clarified the Single-Hop Condition and the SingleHop flag.
o Reshuffled the references.
A.3. Changes between the -02 and -03 versions.
No changes..just a refresh.
A.4. Changes betwen the -03 and -04 versions
o Clarified how this document updates RFC5820.
o Updated ACKs.
Authors' Addresses Authors' Addresses
Alvaro Retana Alvaro Retana
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: aretana@cisco.com EMail: aretana@cisco.com
Stan Ratliff Stan Ratliff
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: sratliff@cisco.com EMail: sratliff@cisco.com
 End of changes. 42 change blocks. 
134 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/