draft-ietf-forces-interoperability-00.txt   draft-ietf-forces-interoperability-01.txt 
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force E. Haleplidis
Internet-Draft University of Patras Internet-Draft University of Patras
Intended status: Informational K. Ogawa Intended status: Informational K. Ogawa
Expires: September 5, 2009 NTT Corporation Expires: December 5, 2009 NTT Corporation
X. Wang X. Wang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
March 4, 2009 June 3, 2009
ForCES Interoperability Draft ForCES Interoperability Draft
draft-ietf-forces-interoperability-00 draft-ietf-forces-interoperability-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in 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.txt. 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 on September 5, 2009. This Internet-Draft will expire on December 5, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes the details of the interoperability test of This document describes the details of the interoperability test of
the Forward and Control Element Separation (ForCES) protocol that the Forward and Control Element Separation (ForCES) protocol that
will take place in the University of Patras in Rio, Greece, in the will take place in the University of Patras in Rio, Greece, in the
fourth week of July 2009. This informational draft provides third week of July 2009. This informational draft provides necessary
necessary information, for all parties who wish to participate in the information, for all parties who wish to participate in the
interoperability test. interoperability test.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4 2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4
2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 4 2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Testbed architecture . . . . . . . . . . . . . . . . . . . . . 8 4. Date, Location and Access . . . . . . . . . . . . . . . . . . 8
4.1. Local configuration . . . . . . . . . . . . . . . . . . . 8 4.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Distributed configuration . . . . . . . . . . . . . . . . 8 4.2. Location . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Scenario 1 - Pre-association Setup . . . . . . . . . . . . 9 5. Testbed architecture . . . . . . . . . . . . . . . . . . . . . 9
5.2. Scenario 2 - TML connection . . . . . . . . . . . . . . . 9 5.1. Local configuration . . . . . . . . . . . . . . . . . . . 9
5.3. Scenario 3 - TML priority channel connection . . . . . . . 9 5.2. Distributed configuration . . . . . . . . . . . . . . . . 10
5.4. Scenario 4 - Association Setup - Association Complete . . 10 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. Scenario 5 - CE query . . . . . . . . . . . . . . . . . . 10 6.1. Scenario 1 - Pre-association Setup . . . . . . . . . . . . 11
5.6. Scenario 6 - Heartbeat monitoring . . . . . . . . . . . . 10 6.2. Scenario 2 - TML priority channels connection . . . . . . 12
5.7. Scenario 7 - Simple Config Command . . . . . . . . . . . . 11 6.3. Scenario 3 - Association Setup - Association Complete . . 12
5.8. Scenario 8 - Association Teardown . . . . . . . . . . . . 11 6.4. Scenario 4 - CE query . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Scenario 5 - Heartbeat monitoring . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.6. Scenario 6 - Simple Config Command . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.7. Scenario 7 - Association Teardown . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. 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].
2. Introduction 2. Introduction
skipping to change at page 4, line 43 skipping to change at page 4, line 43
The TML transports the PL messages. The TML is where the issues of The TML transports the PL messages. The TML is where the issues of
how to achieve transport level reliability, congestion control, how to achieve transport level reliability, congestion control,
multicast, ordering, etc. are handled. It is expected that more than multicast, ordering, etc. are handled. It is expected that more than
one TML will be standardized. The various possible TMLs could vary one TML will be standardized. The various possible TMLs could vary
their implementations based on the capabilities of underlying media their implementations based on the capabilities of underlying media
and transport. However, since each TML is standardized, and transport. However, since each TML is standardized,
interoperability is guaranteed as long as both endpoints support the interoperability is guaranteed as long as both endpoints support the
same TML. All ForCES Protocol Layer implementations MUST be portable same TML. All ForCES Protocol Layer implementations MUST be portable
across all TMLs. Although more than one TML may be standardized for across all TMLs. Although more than one TML may be standardized for
the ForCES Protocol, for the purposes of the interoperability test, the ForCES Protocol, for the purposes of the interoperability test,
the mandated MUST IMPLEMENT SCTP TML [RFC3654] which will be used. the mandated MUST IMPLEMENT SCTP TML [RFC3654] will be used.
3. Definitions 3. Definitions
This document follows the terminology defined by the ForCES This document follows the terminology defined by the ForCES
Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. Requirements in [RFC3654] and by the ForCES framework in [RFC3746].
The definitions below are repeated below for clarity. The definitions below are repeated below for clarity.
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of packets. CEs handle functionality such as the execution of
skipping to change at page 8, line 5 skipping to change at page 8, line 5
ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
ForCES protocol architecture that uses the capabilities of ForCES protocol architecture that uses the capabilities of
existing transport protocols to specifically address protocol existing transport protocols to specifically address protocol
message transportation issues, such as how the protocol messages message transportation issues, such as how the protocol messages
are mapped to different transport media (like TCP, IP, ATM, are mapped to different transport media (like TCP, IP, ATM,
Ethernet, etc), and how to achieve and implement reliability, Ethernet, etc), and how to achieve and implement reliability,
multicast, ordering, etc. The ForCES TML specifications are multicast, ordering, etc. The ForCES TML specifications are
detailed in separate ForCES documents, one for each TML. detailed in separate ForCES documents, one for each TML.
4. Testbed architecture 4. Date, Location and Access
4.1. Date
The date that the Interoperability draft will take place has been
specified at 15-16/07/2009, one and a half week before IETF 75, in
Stockholm.
4.2. Location
Patras is a major harbor of Greece connecting it with Italy.
The University of Patras is located in Rio, 10km east out of Patras.
The following coordinates mark the Electrical Engineering building in
the University.
o North: 38o17'15.99"
o East: 21o47'19.28"
4.3. Access
The best way to come to Greece is by plane to the Athens
International Airport.
From there there are three ways to arrive in the University of
Patras.
1. Renting a car and driving to the University. It is a maximum
2:30 hours drive from the aiport.
2. Via coach station. Get from the airport to the coach station via
X93 bus towards the Kifissos Coach Station. At the Coach Station
there are buses to Patras every 30 minutes. The Bus to Patras
may take about 2:30 - 3:00 hours, and the ride of the X93 bus may
take about 30 mins - 1hour depending on the traffic, so it's
about 3:30 - 4:30 hours away with the wait at the Coach Station.
3. Via Train. It is recommended you already have booked your ticket
beforehand as there are not many trains going to Patras, and
mostly are booked in advanced. Athens International Airport is
connected to Athens Central Railway Station (Larissis Station)
via the Suburban Rail. From there you can take a train to
Patras. The train takes about 3:30 hours to go to Patras. The
Suburban rail will take you about 30 mins. So it's minimum 4:00
hours away.
5. Testbed architecture
Most FEs and CEs should be located locally at the University of Most FEs and CEs should be located locally at the University of
Patras premises. But if some parties would like to participate but Patras premises. But if some parties would like to participate but
cannot attend the interoperability test locally a connection over the cannot attend the interoperability test locally a connection over the
internet MAY be created. internet MAY be created.
The actual test will take place between FEs and CEs of different The actual test will take place between FEs and CEs of different
implementors with different permutations. implementors with different permutations.
4.1. Local configuration All protocol messages of each scenario will be monitored using a
protocol network analyzer to test validity. The current tool that
will be used is a modified tcpdump [tcpdump].
All NE's in all the scenarios will be comprised of one CE and one FE
from different implementors.
5.1. Local configuration
Hardware/Software (CEs and FEs) that will be located within the Hardware/Software (CEs and FEs) that will be located within the
University of Patras premises, will be connected together using University of Patras premises, will be connected together using
switches and hubs. For each permutation there would be a different switches.
subnet ranging starting from 192.168.1.xxx to 192.168.255.xxx to
distinguish them.
For each subnet there will be a machine with IP 192.168.xxx.2 which The scenarios will be tested with only one CE associated with one or
will act as a network monitor using a network analyzer that should be multiple FEs from different implementors. The CE and the FE(s) will
able to show the packets that are traversing the network.The IPs of be connected in one LAN as shown in the following figure.
CEs and FEs will range from 192.168.xxx.3 to 192.168.xxx.254
This will help minimize packet interference with other machines and +-----+
make the testing and the validation easier | CE1 |
|Impl1|
+-----+
|
|
+------------------------------------+
| LAN |
+------------------------------------+
| | | |
| | ... | |
+-----+ +-----+ +-----+ +--------+
| FE1 | | FE2 | | FEn | |Protocol|
|Impl1| |Impl2| |Impln| |Analyzer|
+-----+ +-----+ +-----+ +--------+
4.2. Distributed configuration All scenarios will be tested more than once with permutation of the
CE from different implementors. In the next permutation, the setup
will be as shown in the following figure.
For parties that cannot participate locally there are two current +-----+
propositions: | CE2 |
|Impl2|
+-----+
|
|
+------------------------------------+
| LAN |
+------------------------------------+
| | | |
| | ... | |
+-----+ +-----+ +-----+ +--------+
| FE1 | | FE2 | | FEn | |Protocol|
|Impl1| |Impl2| |Impln| |Analyzer|
+-----+ +-----+ +-----+ +--------+
1. A SCTP over IPsec (VPN) case, where CE and FE are part of a VPN. 5.2. Distributed configuration
2. SCTP over IP with a firewall that will allow only the CEs and FEs For parties that cannot participate, public IPs can be provided and
IPs. associations can be achieved over the internet as seen in the
following figure.
A number of public IPs will be provided by the University of Patras +-----+ +------------+ /\/\/\/\/\ +----------+ +-----+
will be provided for such a case. |FE/CE| |Implementor | \Internet/ |University| |FE/CE|
|ImplX|---| Router |---/ \---| Router |---|ImplY|
+-----+ +------------+ \/\/\/\/\/ +----------+ +-----+
5. Scenarios For interoperability issues, all CEs and FEs MUST implement no
security even in the TML. For security, firewalls MUST be used that
will allow only the specific IPs and the SCTP ports defined in the
SCTP-TML draft [I-D.ietf-forces-sctptml].
All protocol messages of each scenario will be monitored using a 6. Scenarios
protocol network analyzer to test validity.
5.1. Scenario 1 - Pre-association Setup Since the main goal of this interoperability test is to test the
basic protocol functionality, we will limit the test parameters.
Therefore:
1. In the Association Setup Message, all report messages will be
ignored.
2. In the Association Setup Phase, the messages, FEO OperEnable
Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config-
Resp (FE to CE) will be ignored. The CE will assume that the FE
is enabled once the LFBSelectors has been queried.
3. Only FullDataTLVs are going to be used and not SparseData TLV's.
4. There will be no transaction operations.
5. Each message shall have only one LFBSelector TLV, one Operation
TLV and one PathDataTLV per message when these are used.
6.1. Scenario 1 - Pre-association Setup
While the Pre-association setup is not in the ForCES current scope it While the Pre-association setup is not in the ForCES current scope it
is an essential step before CEs and FEs communicate. As the first is an essential step before CEs and FEs communicate. As the first
part in a succesfull CE-FE connection the participating CEs and FEs part in a successfull CE-FE connection the participating CEs and FEs
should be able to be configured. In the Pre-association Phase the should be able to be configured.
following configuration items MUST be setup regarding the CEs:
o Which FE IDs should they be connected In the Pre-association Phase the following configuration items MUST
be setup regarding the CEs:
o The IP of the corresponsing FEs o The CE ID.
o The FE IDs that will be connected to this CE
o The IP of the FEs that will connect
o The TML priority ports.
In the Pre-association Phase the following configuration items MUST In the Pre-association Phase the following configuration items MUST
be setup regarding the FEs: be setup regarding the FEs:
o Which CE IDs should they be connected o The FE ID.
o The IP of the corresponsing CEs o The CE ID that this FE will be connecting to.
Once each element is configured, Scenario 1 is successfull. o The IP of the CE that will connect to
o The TML priority ports.
5.2. Scenario 2 - TML connection Once each element is setup and configured, Scenario 1 is successful.
6.2. Scenario 2 - TML priority channels connection
For the current interoperability test, the SCTP will be used as TML. For the current interoperability test, the SCTP will be used as TML.
The TML connection with the associating element is needed for the The TML connection with the associating element is needed for the
scenario 2 to be successfull. scenario 2 to be successful.
5.3. Scenario 3 - TML priority channel connection
The SCTP-TML draft [I-D.ietf-forces-sctptml] defines 3 priority The SCTP-TML draft [I-D.ietf-forces-sctptml] defines 3 priority
channels, with specific ports: channels, with specific ports:
o High priority - Port number: 6700 o High priority - Port number: 6700
o Medium priority - Port number: 6701 o Medium priority - Port number: 6701
o Lower priority - Port number: 6702 o Lower priority - Port number: 6702
Once these channels have been established with each associated Once these channels have been established with each associated
element, will the Scenario 3 be successfull. element, will the Scenario 2 be successful.
5.4. Scenario 4 - Association Setup - Association Complete 6.3. Scenario 3 - Association Setup - Association Complete
Once the Pre-association phase has been complete in the previous 3 Once the Pre-association phase has been complete in the previous 2
scenarios, CEs and FEs are ready to communicate using the ForCES scenarios, CEs and FEs are ready to communicate using the ForCES
protocol, and enter the Association Setup stage. In this stage the protocol, and enter the Association Setup stage. In this stage the
FEs attempts to join the NE. The following ForCES protocol messages FEs attempts to join the NE. The following ForCES protocol messages
will be exchanged for each CE-FE pair: will be exchanged for each CE-FE pair in the specified order:
o Association Setup Message (from FE to CE) o Association Setup Message (from FE to CE)
o Association Setup Response Message (from CE to FE) o Association Setup Response Message (from CE to FE)
Once the associations has been initialized scenario 4 will have been o Query Message: FEO LFBSelectors(from CE to FE)
successfull.
5.5. Scenario 5 - CE query o Query Response: FEO LFBSelectors response (from FE to CE)
Once the associations has been initialized scenario 3 will have been
successful.
6.4. Scenario 4 - CE query
Once the Association Phase stage has been complete, the FEs and CEs Once the Association Phase stage has been complete, the FEs and CEs
will enter the Established stage. In this stage the FE is will enter the Established stage. In this stage the FE is
continuously updated or queried. The CE should query the FE a continuously updated or queried. The CE should query the FE a
specific value from the FE Object LFB and from the FE Protocol LFB. specific value from the FE Object LFB and from the FE Protocol LFB.
An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and
from the FE Object LFB is the State of the LFB (FEState) from the FE Object LFB is the State of the LFB (FEState)
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages will be exchanged:
o Query Message o Query Message
o Query Response Message o Query Response Message
5.6. Scenario 6 - Heartbeat monitoring 6.5. Scenario 5 - Heartbeat monitoring
The Heartbeat (HB) Message is used for one ForCES element (FE or CE) The Heartbeat (HB) Message is used for one ForCES element (FE or CE)
to asynchronously notify one or more other ForCES elements in the to asynchronously notify one or more other ForCES elements in the
same ForCES NE on its liveness. The default configuration of the same ForCES NE on its liveness. The default configuration of the
Heartbeat Policy of the FE is set to 0 which means, that the FE Heartbeat Policy of the FE is set to 0 which means, that the FE
should not generate any Heartbeat messages. the CE is responsible for should not generate any Heartbeat messages. the CE is responsible for
checking FE liveness by setting the PL header ACK flag of the message checking FE liveness by setting the PL header ACK flag of the message
it sends to AlwaysACK. In this Scenario the CE should send a it sends to AlwaysACK. In this Scenario the CE should send a
Heartbeat message with the ACK flag set to AlwaysACK and the FE Heartbeat message with the ACK flag set to AlwaysACK and the FE
should respond. should respond.
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages will be exchanged:
o Heartbeat Message o Heartbeat Message
5.7. Scenario 7 - Simple Config Command 6.6. Scenario 6 - Simple Config Command
A config message is sent by the CE to the FE to configure LFB A config message is sent by the CE to the FE to configure LFB
components in the FE. A simple config command easily visilble and components in the FE. A simple config command easily visible and
metered would be to change the Heartbeat configuration. This will be metered would be to change the Heartbeat configuration. This will be
done in two steps: done in two steps:
1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force 1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force
the FE to send heartbeats. the FE to send heartbeats.
2. After some heartbeats from the FE, the FE Heartbeat Interval 2. After some heartbeats from the FE, the FE Heartbeat Interval
(FEHI) will be changed. (FEHI) will be changed.
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages will be exchanged:
o Config Message o Config Message
o Config Response Message o Config Response Message
5.8. Scenario 8 - Association Teardown 6.7. Scenario 7 - Association Teardown
In the end, the association must be terminated. There are two In the end, the association must be terminated. There are two
scenarios by which the association maybe terminated: scenarios by which the association maybe terminated:
1. By stopping heartbeats from a FE or a CE. 1. Normal tear down by exchanging Association Teardown Message
2. By externally shutting down/rebooting a FE or a CE. 2. Irregular tear down by stopping heartbeats from a FE or a CE.
Both scenarios may be tested in the interoperability test. 3. Irregular tear down by externally shutting down/rebooting a FE or
a CE.
All scenarios may be tested in the interoperability test.
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages will be exchanged:
o Association Teardown Message o Association Teardown Message
6. Acknowledgements 7. Acknowledgements
TBA The authors of this draft would like to acknowledge and thank the
chair of the ForCES working group Jamal Hadi Salim.
7. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 9. Security Considerations
We should consider security issues if we have connections when there
are associations between CEs and FEs over the internet. Perhaps SCTP
over IPsec may be used.
TBA. Section 9 of the FE-protocol [I-D.ietf-forces-protocol] specifies
security considerations of the ForCES protocol. For this
interoperability test, no security MUST be chosen even for the
distributed architecture.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-forces-model] [I-D.ietf-forces-model]
Halpern, J. and J. Salim, "ForCES Forwarding Element Halpern, J. and J. Salim, "ForCES Forwarding Element
Model", draft-ietf-forces-model-16 (work in progress), Model", draft-ietf-forces-model-16 (work in progress),
October 2008. October 2008.
[I-D.ietf-forces-protocol] [I-D.ietf-forces-protocol]
Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,
Khosravi, H., and W. Wang, "ForCES Protocol Khosravi, H., and W. Wang, "ForCES Protocol
Specification", draft-ietf-forces-protocol-21 (work in Specification", draft-ietf-forces-protocol-22 (work in
progress), February 2009. progress), March 2009.
[I-D.ietf-forces-sctptml] [I-D.ietf-forces-sctptml]
Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping
Layer) for ForCES protocol", draft-ietf-forces-sctptml-02 Layer) for ForCES protocol", draft-ietf-forces-sctptml-02
(work in progress), January 2009. (work in progress), January 2009.
9.2. Informative References 10.2. Informative 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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
skipping to change at page 16, line 5 skipping to change at page 18, line 48
of IP Control and Forwarding", RFC 3654, November 2003. of IP Control and Forwarding", RFC 3654, November 2003.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[tcpdump] "Tcpdump is a linux protocol analyzer. The specific
tcpdump that will be used is a modified tcpdump, by the
chair Jamal Hadi Salim, that can analyze and decode the
ForCES protocol messages.".
Authors' Addresses Authors' Addresses
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Patras, Patras,
Greece Greece
Email: ehalep@ece.upatras.gr Email: ehalep@ece.upatras.gr
Kentaro Ogawa Kentaro Ogawa
 End of changes. 51 change blocks. 
89 lines changed or deleted 215 lines changed or added

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