draft-ietf-forces-discovery-01.txt   draft-ietf-forces-discovery-02.txt 
Furquan Ansari Furquan Ansari
Internet Draft Lucent Tech. Internet Draft Lucent Tech.
Document: draft-ansari-forces-discovery-01.txt Hormuzd Khosravi Document: draft-ietf-forces-discovery-02.txt Hormuzd Khosravi
Expires: April 18, 2006 Intel Corp. Expires: September 5, 2006 Intel Corp.
Working Group: ForCES Jamal Hadi Salim Working Group: ForCES Jamal Hadi Salim
Znyx Networks Znyx Networks
Joel M. Halpern Joel M. Halpern
Megisto Systems Megisto Systems
October 19, 2005 Xiaoyi Guo
Huawei Tech.
March 6, 2006
ForCES Intra-NE Topology Discovery ForCES Intra-NE Topology Discovery
draft-ietf-forces-discovery-01.txt draft-ietf-forces-discovery-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that
applicable patent or other IPR claims of which he or she is aware any applicable patent or other IPR claims of which he or she is
have been or will be disclosed, and any of which he or she becomes aware have been or will be disclosed, and any of which he or she
aware will be disclosed, in accordance with Section 6 of BCP 79. becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.html. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
This Internet-Draft will expire in April 18, 2006. This Internet-Draft will expire on September 5, 2006.
Conventions used in this document Conventions used in this document
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in RFC-2119.
Abstract Abstract
Ansari et al. Expires: Jan 2005 [Page 1] This document describes a mechanism for discovering inter-FE topology,
This document describes a mechanism for discovering inter-FE topology maintenance in Intra-NE. Such a mechanism is essential for
topology and topology maintenance. Such a mechanism is essential for
all these elements in the set to behave as a single Network Element, all these elements in the set to behave as a single Network Element,
as required by the ForCES architecture as well as to perform certain as required by the ForCES architecture as well as to perform certain
optimizations at the FE by making use of the topology. The discovery optimizations at the FE by making use of the topology. The mechanism
mechanism only operates during post-association phase of ForCES only operates during post-association phase of ForCES protocol.
protocol.
Table of Contents Table of Contents
1. Definitions........................................................2
2. Introduction.......................................................3 1. Definitions.........................................................2
2.1. Motivation....................................................3 2. Introduction........................................................3
3. Topology Discovery Mechanism.......................................5 2.1. Motivation....................................................4
3. Topology Discovery Mechanism........................................5
3.1. Minimum requirements..........................................6 3.1. Minimum requirements..........................................6
3.2. Protocol Details..............................................6 3.2. Protocol Details..............................................6
3.2.1. Neighbor Finite State Machine............................7 3.2.1. Neighbor Finite State Machine............................8
3.2.2. Topology Discovery and Maintenance.......................8 3.2.2. Topology Discovery and Maintenance.......................8
3.2.3. Full topology computation at the CE from partial 3.2.3. Full topology computation at the CE from partial
topologies......................................................9 topologies......................................................9
3.3. Protocol and Message Headers..................................9 3.2.4. Update and Maintenance...................................9
3.3.1. TLV definitions.........................................10 3.3. Protocol and Message Headers.................................10
3.4. Inter-FE Topology Discovery Examples.........................10 3.3.1. TLV definitions.........................................11
3.4.1. Forwarding Elements connected in a daisy chain..........12 3.4. Inter-FE Topology Discovery Examples.........................12
3.4.2. Forwarding Elements connected in a ring.................13 3.4.1. Forwarding Elements connected in a daisy chain..........13
4. Security Considerations...........................................14 3.4.2. Forwarding Elements connected in a ring.................14
5. References........................................................14 4. Security Considerations............................................15
5.1. Normative....................................................14 5. References.........................................................15
5.2. Informative..................................................14 5.1. Normative.....................................................15
6. Authors' Addresses................................................14 5.2. Informative...................................................15
7. IANA Considerations...............................................15 6. Authors' Addresses.................................................16
8. Full Copyright Notice.............................................15 7. IANA Considerations................................................16
9. Acknowledgements..................................................16 8. Full Copyright Notice..............................................17
9.Acknowledgements....................................................17
1. Definitions 1. Definitions
Inter-FE topology discovery: Topology discovery relates to how the Inter-FE topology discovery: Topology discovery relates to how the
FEs are interconnected with each other with respect to packet FEs are interconnected with each other with respect to packet
forwarding. This is the complete view of the intra-NE network as forwarding. This is the complete view of the intra-NE network as
seen by the CE. seen by the CE.
Inter-FE topology maintenance: Once the inter-FE topology has been Inter-FE topology maintenance: Once the inter-FE topology has been
discovered, it has to be continuously monitored to ensure that any discovered, it has to be continuously monitored to ensure that any
Ansari et al. Expires: Jan 2005 [Page 2]
changes to the topology are reported to the corresponding CE. This changes to the topology are reported to the corresponding CE. This
represents the steady state and final phase of the protocol. represents the steady state and final phase of the protocol.
Edge FE: edge FE which has a port connected to other NEs or routers
outside of this NE, and also connects to intra-NE FE port.
Intra-NE: It describes the connection and status in a NE, these
status do not contact with outside NEs or other routers.
2. Introduction 2. Introduction
The ForCES framework document [RFC 3746] describes how a set of The ForCES framework document [RFC 3746] describes how a set of
control elements (CEs) and forwarding elements (FEs) interact with control elements (CEs) and forwarding elements (FEs) interact with
each other to form a single network element (NE). It describes the each other to form a single network element (NE). It describes the
ForCES post-association phase protocol working across the Fp ForCES post-association phase protocol working across the Fp
reference point between CE and FE. This document describes an reference point between CE and FE. This document describes an
important aspect of the ForCES operational infrastructure- that of important aspect of the ForCES operational infrastructure- that of
discovering the layout of the different elements within an NE. discovering the layout of the different elements and forwarding
packet within an NE.
The Inter-FE/Intra-NE topology discovery protocol module may be The Inter-FE/Intra-NE topology discovery protocol module may be
implemented as a separate LFB on the FE. The protocol runs in an implemented as some separate LFBs on the FE. The protocol runs in an
ongoing discovery and maintenance mode wherein the LFB maintains ongoing discovery and maintenance mode wherein the LFB maintains
information about the known adjacencies per interface it is operated information about the known adjacencies per interface it is operated
on. Each FE simply maintains its own adjacency tables and notifies on. Each FE simply maintains its own adjacency tables and notifies
the CE of any changes to the adjacency table based on the ForCES the CE of any changes to the adjacency table based on the ForCES
notification mechanism or if the CE explicitly requests an update. notification mechanism or if the CE explicitly requests an update.
It is up to the CE to construct the full topology based on the It is up to the CE to construct the full topology based on the
information received from individual FEs within the NE. Given that information received from individual FEs within the NE and generate
the CE can request and the FEs should report back the topology the NE routing table. Given that the CE can request and the FEs
updates using ForCES protocol, it is implicit that the topology should report back the topology updates using ForCES protocol.
discovery and maintenance operation occurs in the ForCES post-
association phase.
The proposed discovery mechanism is required to scale to a very The proposed discovery mechanism is required to scale to a very
large number of forwarding elements in the NE, with minimal impact large number of forwarding elements in the NE, with minimal impact
on the resources. The following list provides some of the features on the resources. The following list provides some of the features
and goals of the discovery mechanism. and goals of the discovery mechanism.
. Determine connectivity between elements . Determine connectivity between elements
. React to changes in link connectivity . React to changes in link connectivity
. Construct topology information from the collected partial topology . Construct topology information from the collected partial
information topology information
. Tolerant to protocol message losses . Tolerant to protocol message losses
. Applicable to all inter-FE network topologies such as ring, mesh, . Applicable to all inter-FE network topologies such as ring, mesh,
star etc. star etc.
. Cause minimal overhead . Cause minimal overhead
. Agnostic of the network interconnect technology . Agnostic of the network interconnect technology
As noted above, it is implicit that all the phases occur in the
ForCES post-association phase. In other words, the ForCES protocol
association between the CEs and the FEs should already have taken
place.
2.1. Motivation 2.1. Motivation
The ForCES architecture defines a network element (NE) as a single The ForCES architecture defines a network element (NE) as a single
managed entity made up of a collection of FEs and CEs and is managed entity made up of a collection of FEs and CEs and is
indistinguishable from other network elements in the network. This indistinguishable from other network elements in the network. This NE
Ansari et al. Expires: Jan 2005 [Page 3] model definition leads to three types of links from the network
NE model definition leads to three types of links from the network’s
perspective: internal (or intra-NE) links and external (or inter-NE) perspective: internal (or intra-NE) links and external (or inter-NE)
links and control links. Intra-NE links are purely internal to the links and control links. Intra-NE links are purely internal to the
NE and are not exposed to the external world; whereas, inter-NE (or NE and are not exposed to the external world; whereas, inter-NE (or
external) links are exposed to the external world and over which external) links are exposed to the external world and over which
routing adjacencies (such as OSPF, IS-IS, BGP etc.) can be formed. routing adjacencies (such as OSPF, IS-IS, BGP etc.) can be formed.
An NE can contain FEs that have zero or more internal/external links An NE can contain FEs that have zero or more internal/external links
e.g. in Fig. 1, FE3 has two internal links and no external links e.g. in Fig. 1, FE3 has two internal links and no external links
while FE1 and FE2 have two internal links and one external link while FE1 and FE2 have two internal links and one external link
each. Control links are those links that are used for communication each. Control links are those links that are used for communication
between the CE and FE. If the CE and FE are a single Layer 3 hop between the CE and FE. If the CE and FE are a single Layer 3 hop
apart as in Fig.1, the control link is typically a physical link apart as in Fig.1, the control link is typically a physical link
e.g. link A of FE1 in the figure. Control links can be logical as e.g. link A of FE1 in the figure. Control links can be logical as
well. It is important to note that the type definition for given for well. It is important to note that the type definition for given for
a link is only logical, because a given physical link may be a a link is only logical, because a given physical link may be a
combination of more than one type - e.g. it could simultaneously be combination of more than one type - e.g. it could simultaneously be
a control link and an internal link at the same time. a control link and an internal link at the same time. Based on this
link definitions, an FE can be considered to be an internal FE if it
only contains internal links and an edge FE if it contains external
links (and may also contain internal links).
A packet entering a ForCES NE may travel multiple FEs within the NE A packet entering a ForCES NE may travel multiple FEs within the NE
before it exits onto the output link. This requires that the packet before it exits onto the output link. This requires that the packet
be correctly forwarded from the ingress FE to the egress FE. This be correctly forwarded from the ingress FE to the egress FE. This
internal forwarding requires knowledge of the physical FE inter- internal forwarding requires knowledge of the physical FE inter-
connection topology so that the CE can appropriately setup internal connection topology so that the CE can appropriately setup internal
LFB tables at each FE to handle packet traversal in a sane manner. LFB tables at each FE to handle packet traversal in a sane manner.
We use a simple topology discovery mechanism that only operates on
internal links and provides the necessary routing information to
forward the packets from the ingress FE to the egress FE. Further,
the mechanism should be able to reroute around internal link
failures, if a path exists. This makes the NE highly available and
resilient.
NE 1 NE 1
..................................... .....................................
. ----------------- . . ----------------- .
. | CE | . . | CE | .
. ----------------- . ---------- . ----------------- . ----------
. A ^ B ^ C ^ . | NE 1 | . A ^ B ^ C ^ . | NE 1 |
. / | \ . | | . / | \ . | |
. / A v \ . ---------- . / A v \ . ----------
. / ------- B \ . ^ ^ . / ------- B \ . ^ ^
. / +->| FE3 |<-+ \ . <====> / \ . / +->| FE3 |<-+ \ . <====> / \
. / |C | | | \ . / \ . / |C | | | \ . / \
. A v | ------- | v A . v v . A v | ------- | v A . v v
. -------B | |D ------- . -------- --------- . -------B | |D ------- . -------- ---------
. | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 | . | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 |
. | |<--------------->| | . | | | | . | |<--------------->| | . | | | |
. ------- C C ------- . -------- --------- . ------- C C ------- . -------- ---------
. D^ ^B . . D^ ^B .
.....|.......................|........ .....|.......................|........
Ansari et al. Expires: Jan 2005 [Page 4]
| | | |
V v V V
-------- -------- -------- --------
| NE 2 |<--------------->| NE 3 | | NE 2 |<--------------->| NE 3 |
| | | | | | | |
-------- -------- -------- --------
(a) (b) (a) (b)
Figure 1:(a) illustrates the internal/external links and topology Figure 1:(a) illustrates the internal/external links and topology
within a NE. (b) Shows the network topology as seen by external within a NE. (b) Shows the network topology as seen by external
routing protocols routing protocols
3. Topology Discovery Mechanism 3. Topology Discovery Mechanism
Since the topology discovery protocol described here operates in the Since the topology discovery protocol described here operates in the
ForCES post-association phase, it is independent of whether the CE ForCES post-association phase, it is independent of whether the CE
and the FE are a single or multiple hops (layer 2 or layer 3) apart and the FE is a single or multiple hops (layer 2 or layer 3) apart
from each other. It is up to the ForCES association protocol to from each other. It is up to the ForCES association protocol to
determine how to setup the ForCES channel between the CE and FE if determine how to setup the ForCES channel between the CE and FE if
they are multiple hops away. The topology discovery protocol is they are multiple hops away. The topology discovery protocol is
expected to work on all types of media and interfaces such as expected to work on all types of media and interfaces such as point-
point-to-point as well as multi-access links. to-point as well as multi-access links.
In order to keep the discovery and maintenance mechanism as simple In order to keep the discovery and maintenance mechanism as simple as
as possible, the FEs only maintain relationships with their possible, the FEs only maintain relationships with their respective
respective neighbors to determine the status of the neighbors. No neighbors to determine the status of the neighbors. No databases
databases are exchanged between the neighbors. This implies that the are exchanged between the neighbors. This implies that the
topology view for each FE is only limited to the adjacent elements. topology view for each FE is only limited to the adjacent elements.
This partial topology information may be reported back to the CE (or This partial topology information may be reported back to the CE (or
queried by the CE) over the ForCES protocol using the ForCES queried by the CE) over the ForCES protocol using the ForCES
notification mechanism. Since the CE receives such information from notification mechanism. Since the CE receives such information from
all the FEs, it can easily construct the full topology from all the FEs, it can easily construct the full topology from
individual partial topologies reported by each FE. Once the CE individual partial topologies reported by each FE. Once the CE
constructs the full topology, such information can be passed to the constructs the full topology, such information can be passed to the
FEs, if needed (depending on policy). The FEs may use such FEs, if needed (depending on policy). The FEs may use such
information for dynamic intra-NE route calculation or certain other information for dynamic intra-NE route calculation or certain other
optimizations. optimizations.
Topology information is needed by a lot of LFBs and associated Topology information is needed by a lot of LFBs and associated
services that span multiple FEs within a NE. In the case where the services that span multiple FEs within a NE. In the case where the
FE aids the CE in offloading the table updates, then it makes sense FE aids the CE in offloading the table updates, then it makes sense
for the FE to be topology aware. It is sometimes also helpful to for the FE to be topology aware. It is sometimes also helpful to
keep full topology information at the FEs for cases such as “message keep full topology information at the FEs for cases such as message
snooping” optimizations. For example, if an FE is aware of the snooping optimizations. For example, if an FE is aware of the
topology, it could snoop on messages sent to other FEs (e.g. topology, it could snoop on messages sent to other FEs (e.g.,
broadcasts, multicasts) and update its own tables dynamically broadcasts, multicasts) and update its own tables dynamically
without involving the CE. Another example would be FE-FE primary- without involving the CE. Another example would be FE-FE primary-
Ansari et al. Expires: Jan 2005 [Page 5]
backup handover scenario. With each FE being fully aware of the backup handover scenario. With each FE being fully aware of the
complete topology, the backup FE can take over the responsibilities complete topology, the backup FE can take over the responsibilities
of the primary without involving the CE for such a handover. of the primary without involving the CE for such a handover.
3.1. Minimum requirements 3.1 Minimum requirements
In order for the protocol to work as described, the following In order for the protocol to work as described, the following
assumptions are made. assumptions are made.
. Each element has been configured with their respective IDs . Each element has been configured with their respective IDs
(CEID, FEID) (CEID, FEID)
. Element bindings process has already taken place. In other . Element bindings process has already taken place. In other
words, the CE know all the FEs it wants to control and each FE words, the CE know all the FEs it wants to control and each FE
knows which CE is allowed to control it. knows which CE is allowed to control it.
. The ForCES protocol association has already taken place between . The ForCES protocol association has already taken place between
the CE and the FE in question. the CE and the FE in question.
. The protocol is enabled on the required interfaces. . The protocol is enabled on the required interfaces.
Note that these are configuration requirements and are satisfied by Note that these are configuration requirements and are satisfied by
the respective managers (CEM/FEM). the respective managers (CEM/FEM).
3.2. Protocol Details 3.2 Protocol Details
Once the ForCES protocol association has been established between a Once the ForCES protocol association has been established between a
CE and a given FE i.e. it is in post-association phase, the CE CE and a given FE i.e. it is in post-association phase, the CE
starts sending/advertising Hello/Probe messages to the FE’s starts sending/advertising Hello/Probe messages to the FE
neighbors such that the messages go through the given FE. In other neighbors such that the messages go through the given FE. In other
words, it looks like the given FE is generating probe messages to words, it looks like the given FE is generating probe messages to
the neighbor (except that these messages are coming from the CE over the neighbor (except that these messages are coming from the CE over
the ForCES protocol first). However, this functionality of the ForCES protocol first). However, this functionality of
generating probe messages by the CE can be offloaded to the FE generating probe messages by the CE can be offloaded to the FE
itself (to be more precise, to an FE LFB) so that the FE can itself (to be more precise, to an FE LFB) so that the FE can
originate and terminate the probe messages. This provides better originate and terminate the probe messages. This provides better
scalability of the CE and it’s resources. The CE can now simply scalability of the CE and it resources. The CE can now simply query
query each FE’s neighbor relationship database and register for any each FE neighbor relationship database and register for any events
events related to topology changes. related to topology changes.
All Hello/Probe messages travel a single PE hop and are not routed All Hello/Probe messages travel a single PE hop and are not routed
to other elements beyond the first hop. An on-link IP multicast to other elements beyond the first hop. An on-link IP multicast
address is used for sending all Hello packets. The packets should be address is used for sending all Hello packets. The packets should be
sent with a TTL of 255 and ignored on receipt if the TTL is not 254 sent with a TTL of 255 and ignored on receipt if the TTL is not 254
(based on some of the recommendations from the generalized TTL (based on some of the recommendations from the generalized TTL
security mechanism to use TTL 255 rather than TTL 1). Hello packets security mechanism to use TTL 255 rather than TTL 1). Hello packets
are only sent on interfaces configured for topology discovery are only sent on interfaces configured for topology discovery
protocol operation. Further, the Hello messages will be multicast on protocol operation. Further, the Hello messages will be multicast on
multicast capable links. Each FE topology LFB component maintains multicast capable links. Each FE topology LFB component maintains
the neighbor relationships as long as the Hello messages are the neighbor relationships as long as the Hello messages are
received from the neighbor. If it does not receive Hello messages received from the neighbor. If it does not receive Hello messages
after a given (configured) period of time (called FE Neighbor dead after a given (configured) period of time (called FE Neighbor dead
interval), it deletes the entry from the database and reports this interval), it deletes the entry from the database and reports this
Ansari et al. Expires: Jan 2005 [Page 6]
change to the CE in the form of an event-notification message over change to the CE in the form of an event-notification message over
the ForCES protocol. This ensures that the CE has the complete and the ForCES protocol. This ensures that the CE has the complete and
up-to-date information of the underlying topology of the Inter-FE up-to-date information of the underlying topology of the Inter-FE
network. network.
The Hello message contains information necessary for discovering and The Hello message contains information necessary for discovering and
maintaining neighbor relationships. It contains the PE ID, type of maintaining neighbor relationships. It contains the PE ID, type of
protocol element (i.e. CE or FE), interval between any two messages, protocol element (i.e. CE or FE), interval between any two messages,
interval for deeming a neighbor inactive, capability information interval for deeming a neighbor inactive, capability information etc.
etc. This is, in some ways, similar to the capabilities of the OSPF This is, in some ways, similar to the capabilities of the OSPF Hello
Hello protocol. protocol.
On receiving the Hello messages from a neighbor, the FE responds On receiving the Hello messages from a neighbor, the FE responds back
back with its own Hello message in a packet format similar to the with its own Hello message in a packet format similar to the one
one received from the neighbor. Essentially, both sides are received from the neighbor. Essentially, both sides are
independently sending Hello messages to each other and listing their independently sending Hello messages to each other and listing their
neighbor table. Also, each neighbor will see itself listed on its neighbor table. Also, each neighbor will see itself listed on its
neighbors Hello message. This ensures bi-directionality of the link neighbors Hello message. This ensures bi-directionality of the link
between any two neighbors. between any two neighbors.
The operation is concisely described by the following steps: The operation is concisely described by the following steps:
. CE activates the topology LFB/component on the FE to initialize on . CE activates the topology LFB/component on the FE to initialize on
specific ports specific ports
. FE topology LFB/component sends neighbor probes/hellos . FE topology LFB/component sends neighbor probes/hellos
. CE queries FE for its neighbors . CE queries FE for its neighbors
. FE continues to send these probes afterwards (maintenance) and . FE continues to send these probes afterwards (maintenance) and
updates asynchronously any new updates updates asynchronously any new updates
Note: We would like to point out here that the Hello messaging Note: We would like to point out here that the Hello messaging
mechanism can very well be replaced by the BFD (Bi-Directional mechanism can very well be replaced by the BFD (Bi-Directional
Forwarding Detection) protocol in the future since it performs Forwarding Detection) protocol in the future since it performs
similar task of detecting bi-directional faults between two similar task of detecting bi-directional faults between two
forwarding engines. Further, BFD protocol has the ability to be forwarding engines. Further, BFD protocol has the ability to be
bootstrapped by any other protocol that automatically forms peer, bootstrapped by any other protocol that automatically forms peer,
neighbor or adjacency relationships to seed BFD endpoint discovery. neighbor or adjacency relationships to seed BFD endpoint discovery.
skipping to change at line 328 skipping to change at page 8, line 11
Note: We would like to point out here that the Hello messaging Note: We would like to point out here that the Hello messaging
mechanism can very well be replaced by the BFD (Bi-Directional mechanism can very well be replaced by the BFD (Bi-Directional
Forwarding Detection) protocol in the future since it performs Forwarding Detection) protocol in the future since it performs
similar task of detecting bi-directional faults between two similar task of detecting bi-directional faults between two
forwarding engines. Further, BFD protocol has the ability to be forwarding engines. Further, BFD protocol has the ability to be
bootstrapped by any other protocol that automatically forms peer, bootstrapped by any other protocol that automatically forms peer,
neighbor or adjacency relationships to seed BFD endpoint discovery. neighbor or adjacency relationships to seed BFD endpoint discovery.
3.2.1. Neighbor Finite State Machine 3.2.1. Neighbor Finite State Machine
In order to obtain bi-directionality verification of the links, and In order to obtain bi-directionality verification of the links, and
to make the protocol more robust, a neighbor finite state machine is to make the protocol more robust, a neighbor finite state machine is
needed. It consists of the following three states: needed. It consists of the following three states:
Neighbor-down: This is the initial state of the neighbor Neighbor-down: This is the initial state of the neighbor
conversation. It indicates that there has been no recent information conversation. It indicates that there has been no recent information
received from the neighbor received from the neighbor
Ansari et al. Expires: Jan 2005 [Page 7]
Neighbor-heard: In this state, a Hello packet was recently seen from Neighbor-heard: In this state, a Hello packet was recently seen from
the neighbor. However, bi-directional communication has not been the neighbor. However, bi-directional communication has not been
fully established with the neighbor (i.e. the PE itself was not fully established with the neighbor (i.e. the PE itself was not
listed in the neighbor’s Hello packet – which is the check for bi- listed in the neighbor Hello packet which is the check for bi-
directionality). All neighbors in this state (or higher) are listed directionality). All neighbors in this state (or higher) are listed
in the Hello packets sent from the associated interface. in the Hello packets sent from the associated interface.
Neighbor-adjacent: In this state, the communication between the two Neighbor-adjacent: In this state, the communication between the two
neighbors is bi-directional. This has been assured by the Hello neighbors is bi-directional. This has been assured by the Hello
protocol operation. This state corresponds to the final steady state protocol operation. This state corresponds to the final steady state
of the protocol. of the protocol.
3.2.2. Topology Discovery and Maintenance 3.2.2. Topology Discovery and Maintenance
skipping to change at line 382 skipping to change at page 9, line 17
may decide to make use of this feature in different ways, so the may decide to make use of this feature in different ways, so the
capability to obtain such topology information should exist. capability to obtain such topology information should exist.
The periodic Hello messages maintain PE neighbor relationships. The periodic Hello messages maintain PE neighbor relationships.
Any change in the link or neighbor status causes the FE to generate Any change in the link or neighbor status causes the FE to generate
an asynchronous/event-driven message to the CE indicating this an asynchronous/event-driven message to the CE indicating this
change. The mechanism defined in [ForCESP] is used for delivering change. The mechanism defined in [ForCESP] is used for delivering
event-driven messages from the FE to the CE. This involves the CE event-driven messages from the FE to the CE. This involves the CE
subscribing to such event-driven messages from the FE. subscribing to such event-driven messages from the FE.
The CE aggregates the partial topology information received from
each FE and generates the inter-FE topology. With this complete
knowledge of the inter-FE topology, it can now make appropriate
Ansari et al. Expires: Jan 2005 [Page 8]
updates to the LFB tables on each FE to move packets inside the NE –
from ingress FE to egress FE, assuming that the destination of the
packet is not the current NE itself. Any changes in the internal
link states (and hence the topology) requires that the CE
reconfigure the LFB tables on the FEs based on the most up-to-date
information to ensure that the packets do not end up in a black hole
or enter a loop.
3.2.3. Full topology computation at the CE from partial topologies 3.2.3. Full topology computation at the CE from partial topologies
The CE receives neighbor relationships information from each FE that The CE receives neighbor relationships information from each FE that
it uses to construct the full topology of the internal network. Each it uses to construct the full topology of the internal network. Each
FE’s neighbor relationship table contains information regarding the FE neighbor relationship table contains information regarding the
local element ID, local port connecting the neighbor, the neighbor’s local element ID, local port connecting the neighbor, the neighbor
ID, the neighbor’s port and any optional additional information. ID, the neighbor port and any optional additional information.
Note that the fact that the FE already knows the neighbor’s port Note that the fact that the FE already knows the neighbor port
information implies that it received the probe/hello messages from information implies that it received the probe/hello messages from
the neighbor on that port in response to the hello sent and was, the neighbor on that port in response to the hello sent and was,
therefore, able to establish bi-directionality of the link. If all therefore, able to establish bi-directionality of the link. If all
the links in the internal network are point-to-point links, the CE the links in the internal network are point-to-point links, the CE
simply has to aggregate all the neighbor relationship tables simply has to aggregate all the neighbor relationship tables
obtained from all the FEs to generate the full topology. If we obtained from all the FEs to generate the full topology. If we
assume the topology to be a graph, each edge of the graph will be assume the topology to be a graph, each edge of the graph will be
present twice essentially providing the same information from the present twice essentially providing the same information from the
two endpoints of the graph. After deleting all the duplicate entries two endpoints of the graph. After deleting all the duplicate entries
(and thus reducing the table size by half), the CE now has accurate (and thus reducing the table size by half), the CE now has accurate
view of the full topology. Please refer section 3.4 [Fig. 3(b)] for view of the full topology. Please refer section 3.4 [Fig. 3(b)] for
more details. more details.
[Sub-section on generating full topology from partial topology [TBD: Sub-section on generating full topology from partial
information for broadcast/multi-access, point-to-multipoint etc. topology information for broadcast/multi-access, point-to-
type of links] multipoint etc. type of links]
3.2.4. Update and Maintenance
The periodic Hello messages maintain PE neighbor relationships. Any
change in the link or neighbor status causes the FE to generate an
asynchronous/event-driven message to the CE indicating this change.
The mechanism defined in [ForCESP] is used for delivering event-
driven messages from the FE to the CE. This involves the CE
subscribing to such event-driven messages from the FE.
The CE aggregates the partial topology information received from
each FE and generates the inter-FE topology. With this complete
knowledge of the inter-FE topology, it can now make appropriate
updates to the LFB tables and routing table on each FE to move
packets inside the NE from ingress FE to egress FE, assuming that
the destination of the packet is not the current NE itself. Any
changes in the internal link states (and hence the topology)
requires that the CE reconfigure the LFB tables on the FEs based
on the most up-to-date information to ensure that the packets do not
end up in a black hole or enter a loop.
3.3. Protocol and Message Headers 3.3. Protocol and Message Headers
The protocol message consists of a fixed length header (16 bytes) The protocol hello message consists of a fixed length header (16
followed by one or more optional TLVs. The format of the message is bytes) followed by one or more optional TLVs. The format of the
as follows. message is as follows.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Flags | Packet Length | | Version | Flags | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Port ID | | Checksum | Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE ID | | PE ID |
Ansari et al. Expires: Jan 2005 [Page 9]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Value ... | | TLV-Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure (2) Figure (2)
Version: Version number of this protocol. Currently acceptable value Version (8 bit):
Version number of this protocol. Currently acceptable value
is 0x01 is 0x01
Flags: These indicate whether the message is sent by a FE, (0x01) or Flags (8 bit):
These indicate whether the message is sent by a FE, (0x01) or
CE (0x02). More options may be defined in the future. CE (0x02). More options may be defined in the future.
Packet Length: The length of the protocol message in bytes, Packet Length (16 bit):
including the header and the following TLVs. The length of the protocol message in bytes, including the
header and the following TLVs.
Checksum: 16-bit checksum for the protocol message. The checksum Checksum (16 bit):
calculation does not include the IP header. Checksum for the protocol message. The checksum calculation
does not include the IP header.
Port ID: This indicates the port on which this packet was sent out Port ID (16 bit):
by the sender useful for topology construction. This indicates the port on which this packet was sent out by
the sender useful for topology construction.
PE ID: This is the 32-bit identifier of the sender. It could either PE ID (32 bit):
be CE ID or FE ID, depending on the sender. 32-bit identifier of the sender. It could either be CE ID or
FE ID, depending on the sender. See more details in ForCES
protocol section 6.1.
TLV Type (16 bit):
The TLV type field is two octets, and indicates the
type of data encapsulated within the TLV.
TLV Length (16 bit):
The TLV Length field is two octets, and indicates
the length of this TLV including the TLV Type, TLV Length,
and the TLV data in octets.
TLV Value (variable):
The TLV Value field carries the data. For extensibility,
the TLV value may in fact be a TLV. TLVs must be 32 bit
aligned. Padding used for the alignment must be zero on
transmission and must be ignored upon reception.
3.3.1. TLV definitions
The protocol header is followed by one or many TLVs. The following The protocol header is followed by one or many TLVs. The following
TLVs types are defined: TLVs types are defined:
Hello TLV: Indicates the Hello message as exchanged by the Hello TLV: Indicates the Hello message as exchanged by the neighbors.
neighbors. The TLV defines the common hello parameters such as the The TLV defines the common hello parameters such as the
Hello Interval, Hold time, Uni-directional targeted Hellos, Sequence Hello Interval, Hold time, Unidirectional targeted Hellos,
space number, if needed etc. Sequence space number, if needed etc.
Data TLV: Indicates the neighbor or the topology information from
CE or neighbor FE.
Capabilities TLV: Provides the capabilities information - TBD Capabilities TLV: Provides the capabilities information - TBD
Vendor specific TLV: TBD Vendor specific TLV: TBD
3.3.1. TLV definitions Other TLV: TBD
TBD
3.4. Inter-FE Topology Discovery Examples 3.4. Inter-FE Topology Discovery Examples
The following examples illustrate the topology discovery mechanism. The following examples illustrate the topology discovery mechanism.
Ansari et al. Expires: Jan 2005 [Page 10]
For sake of simplicity, we assume that there is only one CE per NE. For sake of simplicity, we assume that there is only one CE per NE.
The FEIDs of the FEs in the topologies below are FE1, FE2, FE3, and The FEIDs of the FEs in the topologies below are FE1, FE2, FE3, and
FE4. Each FE has port IDs labeled alphabetically. This is also the FE4. Each FE has port IDs labeled alphabetically. This is also the
case with the CE. case with the CE.
----------------- -----------------
| CE | | CE |
----------------- -----------------
A ^ B ^ C ^ A ^ B ^ C ^
/ | \ / | \
/ A v \ / A v \
/ ------- B \ / ------- B \
/ +->| FE3 |<-+ \ / +->| FE3 |<-+ \
/ |C | | | \ / |C | | | \
A v | ------- | v A A v 2| ------- |1 v A
-------B | |E ------- -------B | |E -------
| FE1 |<-+ +->| FE2 | | FE1 |<-+ +->| FE2 |
| |<--------------->| | | |<--------------->| |
------- C D ------- ------- C 5 D -------
E ^ D| C ^ | B E ^ D| C ^ | B
| | | | | | | |
| v | v | v | v
FE3 Control Element reachability Table FE3 Control Element reachability Table
-------------------------------------- --------------------------------------
<Dest Addr> <local intf> <Dest Addr> <local intf>
CE A CE A
-------------------------------------- --------------------------------------
FE3 NEIGHBOR ASSOCIATION TABLE FE3 NEIGHBOR ASSOCIATION TABLE
----------------------------------------------- -----------------------------------------------
<local intf> <neighbor_FEID> <neighbor_portID> <local intf> <neighbor_FEID> <neighbor_portID>
B FE2 E B FE2 E
C FE1 B C FE1 B
---------------------------------------------- -----------------------------------------------
Figure 4. (a) Full mesh among FE1, FE2, and FE3
Figure 3. (a) Full mesh among FE1, FE2, and FE3
During the element-binding phase, each FE sends out hello messages During the element-binding phase, each FE sends out hello messages
with its FEID and Port ID (as outlined earlier) to all of its with its FEID and Port ID (as outlined earlier) to all of its
neighbors. Since each neighboring FE also listens to such messages, neighbors. Since each neighboring FE also listens to such messages,
it receives the hello message and adds it to the neighbor it receives the hello message and adds it to the neighbor
association table, which may look like that shown in Fig.4(a). In association table, which may look like that shown in Fig.4(a). In
Ansari et al. Expires: Jan 2005 [Page 11] the topology discovery phase, which is post ForCES association stage,
the topology discovery phase, which is post ForCES association the CE queries each FE about its neighbor table. The FE responds
stage, the CE queries each FE about its neighbor table. The FE back with the partial topology information available through its
responds back with the partial topology information available neighbor relationships. Both the query and the response are carried
through its neighbor relationships. Both the query and the response by the ForCES protocol. The CE collects the partial topology
are carried by the ForCES protocol. The CE collects the partial information from all the FEs in the NE and aggregates this
topology information from all the FEs in the NE and aggregates this
information to fully construct the inter-FE topology. Any changes to information to fully construct the inter-FE topology. Any changes to
the FE neighbor table, e.g. when a link state changes, generates a the FE neighbor table, e.g. when a link state changes, generates a
trigger/update message to the CE. The new information is used to trigger/update message to the CE. The new information is used to
recalculate the new topology and subsequently the CE takes recalculate the new topology and subsequently the CE takes
appropriate actions based on the new topology such as updating the appropriate actions based on the new topology such as updating the
packet forwarding tables on the FEs. packet forwarding tables on the FEs.
The following examples show the neighbor association tables. The following examples show the neighbor association tables.
3.4.1. Forwarding Elements connected in a daisy chain 3.4.1. Forwarding Elements connected in a daisy chain
-------------- --------------
| CE | | CE |
-------------- --------------
A ^ ^ B ^ ^ D A ^ ^ B ^ ^ D
skipping to change at line 567 skipping to change at page 14, line 4
-------------------------------- ------------------------------ -------------------------------- ------------------------------
<locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port>
B FE2 E E FE1 B B FE2 E E FE1 B
B FE3 E B FE3 E
FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE
-------------------------------- ----------------------------- -------------------------------- -----------------------------
<locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port>
B FE4 D D FE3 B B FE4 D D FE3 B
E FE2 B E FE2 B
Ansari et al. Expires: Jan 2005 [Page 12]
CE Topology (Aggregate)View CE Topology View CE Topology (Aggregate)View CE Topology View
-------------------------------- ------------------------------ -------------------------------- ------------------------------
<Node> <Port> <Node> <Port> <Node> <Port> <Node> <Port> <Node> <Port> <Node> <Port> <Node> <Port> <Node> <Port>
FE1 B FE2 E\ FE1 B FE2 E FE1 B FE2 E\ FE1 B FE2 E
FE2 E FE1 B/ => FE2 B FE3 E FE2 E FE1 B/ => FE2 B FE3 E
FE2 B FE3 E\ FE3 B FE4 D FE2 B FE3 E\ FE3 B FE4 D
FE3 E FE2 B/ ------------------------------ FE3 E FE2 B/ ------------------------------
FE3 B FE4 D\ FE3 B FE4 D\
FE4 D FE3 B/ FE4 D FE3 B/
-------------------------------- --------------------------------
Fig.3(b) Multiple FEs in a daisy chain Fig.4 (b) Multiple FEs in a daisy chain
3.4.2. Forwarding Elements connected in a ring 3.4.2. Forwarding Elements connected in a ring
^ | ^ |
D| v E D| v E
----------- A ----------- A
| FE1 |<-----------------------| | FE1 |<-----------------------|
----------- | ----------- |
C ^ ^ B | C ^ ^ B |
/ \ | / \ |
skipping to change at line 607 skipping to change at page 15, line 4
| \ / C ^ ^ B | \ / C ^ ^ B
| \ / | | | \ / | |
| D v E v | | | D v E v | |
| ----------- A | | | ----------- A | |
| | FE4 |<----------------------| | | | FE4 |<----------------------| |
| ----------- | | ----------- |
| C | ^ B | | C | ^ B |
| v | | | v | |
| | | |
|----------------------------------------| |----------------------------------------|
Ansari et al. Expires: Jan 2005 [Page 13]
FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE
-------------------------------- ----------------------------- ------------------------------- -----------------------------
<locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port>
B FE3 C E FE4 D B FE3 C E FE4 D
C FE2 D D FE1 C C FE2 D D FE1 C
FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE
-------------------------------- ----------------------------- -------------------------------- -----------------------------
<locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port> <locl intf> <nbr_FEID> <nbr_port>
B FE4 E D FE2 E B FE4 E D FE2 E
C FE1 B E FE3 B C FE1 B E FE3 B
Fig. 3(c) Multiple FEs connected in a ring Fig. 4(c) Multiple FEs connected in a ring
4. Security Considerations 4. Security Considerations
Like all protocols, this protocol will have security issues as well. The ForCES protocol should ensure the communication security between
These issues will be researched in detail in future draft versions. CEs and FEs. FEs should ensure that only properly authenticated ForCES
protocol participants are performing such manipulations.
5. References 5. References
5.1. Normative 5.1 Normative
[RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for
Separation of IP Control and Forwarding", RFC 3654, [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654,
November 2003. November 2003.
[ForCESP] F P Team, "ForCES protocol specification", [ForCESP] F P Team, "ForCES protocol specification",
draft-ietf-forces-protocol-00.txt, Sept 2004. draft-ietf-forces-protocol-05.txt, Nov 2006.
5.2. Informative 5.2 Informative
[OSPF] J. Moy, “OSPF Version 2”, 1998, RFC 2328. [OSPF] J. Moy, OSPF Version 2, 1998, RFC 2328.
[BGP] Y. Rekhter, T. Li, “A Border Gateway Protocol 4 (BGP-4)”,
[BGP] Y. Rekhter, T. Li, Border Gateway Protocol 4 (BGP-4)
1995, RFC 1771. 1995, RFC 1771.
[IS-IS] R. Collela et al., “Guidelines for OSI NSAP Allocation in
the Internet”, 1994, RFC 1629. [IS-IS] R. Collela et al., guidelines for OSI NSAP Allocation in
the Internet 1994, RFC 1629.
6. Authors' Addresses 6. Authors' Addresses
Furquan Ansari Furquan Ansari
Bell Labs Research, Lucent Tech. Bell Labs Research, Lucent Tech.
Ansari et al. Expires: Jan 2005 [Page 14]
101 Crawfords Corner Road 101 Crawfords Corner Road
Holmdel, NJ 07733 Holmdel, NJ 07733
USA USA
Phone: +1 732-949-5249 Phone: +1 732-949-5249
Email: furquan@lucent.com Email: furquan@lucent.com
Hormuzd Khosravi Hormuzd Khosravi
Intel Intel
2111 N.E. 25th Avenue JF3-206 2111 N.E. 25th Avenue JF3-206
Hillsboro, OR 97124-5961 Hillsboro, OR 97124-5961
skipping to change at line 675 skipping to change at page 16, line 30
Phone: +1 503 264 0334 Phone: +1 503 264 0334
Email: hormuzd.m.khosravi@intel.com Email: hormuzd.m.khosravi@intel.com
Jamal Hadi Salim Jamal Hadi Salim
ZNYX Networks ZNYX Networks
Ottawa, Ontario, Canada Ottawa, Ontario, Canada
Email: hadi@znyx.com Email: hadi@znyx.com
Joel M. Halpern Joel M. Halpern
Megisto systems, Inc. Megisto systems, Inc.
20251 Century Blvd. 0251 Century Blvd.
Germantown, MD, 20874-1162, USA Germantown, MD, 20874-1162, USA
Phone: +1 301 444 17 Phone: +1 301 444 17
Email: jhalpern@megisto.com Email: jhalpern@megisto.com
Xiaoyi Guo
Huawei Tech.
No.3 Xinxi Rd., Shang-Di,
Hai-Dian District Beijing P.R. China
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations at this point since the protocol completely
operates within an NE. There are no IANA considerations at this point since the protocol
completely operates within an NE.
8. Full Copyright Notice 8. Full Copyright Notice
"Copyright (C) The Internet Society (2005). This document is subject "Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights." except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on "This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Ansari et al. Expires: Jan 2005 [Page 15] 9. Acknowledgments
9. Acknowledgements
We would like to thank Thyaga Nandagopal of Lucent Technologies for We would like to thank Thyaga Nandagopal of Lucent Technologies for
his thoughts and contributions to the initial draft. his thoughts and contributions to the initial draft.
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Ansari et al. Expires: Jan 2005 [Page 16]
 End of changes. 97 change blocks. 
177 lines changed or deleted 221 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/