draft-ietf-forces-interop-05.txt   draft-ietf-forces-interop-06.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Intended status: Informational K. Ogawa Intended status: Informational K. Ogawa
Expires: July 7, 2013 NTT Corporation Expires: August 10, 2013 NTT Corporation
E. Haleplidis E. Haleplidis
University of Patras University of Patras
M. Gao M. Gao
Hangzhou BAUD Networks Hangzhou BAUD Networks
J. Hadi Salim J. Hadi Salim
Mojatatu Networks Mojatatu Networks
January 3, 2013 February 6, 2013
Interoperability Report for Forwarding and Control Element Separation Interoperability Report for Forwarding and Control Element Separation
(ForCES) (ForCES)
draft-ietf-forces-interop-05 draft-ietf-forces-interop-06
Abstract Abstract
This document captures test results from the second Forwarding and This document captures results of the second Forwarding and Control
control Element Separation (ForCES) interoperability test which took Element Separation (ForCES) interoperability test which took place on
place on February 24-25, 2011 in the Internet Technology Lab (ITL) of February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang
Zhejiang Gongshang University, China. Gongshang University, China. The document is an update to RFC 6053,
which captured the results of the first ForCES interoperability test.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 7, 2013. This Internet-Draft will expire on August 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document captures the results of the second interoperability This document captures results of the second interoperability test of
test of the Forwarding and control Element Separation (ForCES) the Forwarding and Control Element Separation (ForCES) which took
Framework which took place February 24-25, 2011 in the Internet place February 24-25, 2011 in the Internet Technology Lab (ITL) of
Technology Lab (ITL) of Zhejiang Gongshang University, China. The Zhejiang Gongshang University, China. The test involved several
test involved several documents namely: ForCES protocol [RFC5810] , documents namely: ForCES protocol [RFC5810] , ForCES FE model
ForCES FE model [RFC5812] , ForCES TML [RFC5811] , ForCES LFB Library [RFC5812] , ForCES TML [RFC5811] , ForCES LFB Library
[I-D.ietf-forces-lfb-lib] and ForCES CE HA specification [I-D.ietf-forces-lfb-lib] and ForCES CE HA specification
[I-D.ietf-forces-ceha]. Three independent ForCES implementations [I-D.ietf-forces-ceha]. Three independent ForCES implementations
participated in the test. participated in the test.
Scenarios of ForCES LFB Operation, TML with IPSec, CE High Scenarios of ForCES LFB Operation, TML with IPSec, CE High
Availability, and Packet Forwarding are constructed. Series of Availability, and Packet Forwarding are constructed. Series of
testing items for every scenario are carried out and interoperability testing items for every scenario are carried out and interoperability
results are achieved. Popular packet analyzers Ethereal/ results are achieved. Popular packet analyzers Ethereal/
Wireshark[Ethereal] and Tcpdump[Tcpdump] are used to verify the wire Wireshark[Ethereal] and Tcpdump[Tcpdump] are used to verify the wire
results. results.
The first interoperability test on ForCES was held in July 2008 at This document is an update to [RFC6053], which captured the results
the University of Patras, Greece. The test focused on validating the of the first ForCES interoperability test. The first test on ForCES
basic semantics of the ForCES protocol and ForCES FE model. The test was held in July 2008 at the University of Patras, Greece. The test
results were captured by [RFC6053] . focused on validating the basic semantics of the ForCES protocol and
ForCES FE model. The test results were captured by [RFC6053] .
1.1. ForCES Protocol 1.1. ForCES Protocol
The ForCES protocol works in a master-slave mode in which FEs are The ForCES protocol works in a master-slave mode in which FEs are
slaves and CEs are masters. The protocol includes commands for slaves and CEs are masters. The protocol includes commands for
transport of Logical Function Block (LFB) configuration information, transport of Logical Function Block (LFB) configuration information,
association setup, status, and event notifications, etc. The reader association setup, status, and event notifications, etc. The reader
is encouraged to read the ForCES protocol specification [RFC5810] for is encouraged to read the ForCES protocol specification [RFC5810] for
further information. further information.
skipping to change at page 9, line 35 skipping to change at page 9, line 35
| | | | | | | |
192.168.50.0/24 | | 192.168.60.0/24 192.168.50.0/24 | | 192.168.60.0/24
| 192.168.10.0/24 192.168.40.0/24 | | 192.168.10.0/24 192.168.40.0/24 |
.1 | |.11 |.11 |.1 .1 | |.11 |.11 |.1
+--------+ +---------------------------------------+ +--------+ +--------+ +---------------------------------------+ +--------+
|Terminal| | Smartbits | |Terminal| |Terminal| | Smartbits | |Terminal|
+--------+ +---------------------------------------+ +--------+ +--------+ +---------------------------------------+ +--------+
Figure 2: Testbed Configuration Located in ITL Lab,China Figure 2: Testbed Configuration Located in ITL Lab,China
Hardwares and Softwares (CE and FE) of Greece that were located Hardware and Software (CE and FE) of Greece those were located within
within the University of Patras, Greece, were connected together the University of Patras, Greece, were connected together using LAN
using LAN as shown in Figure 3. The Internet is connected via a VPN as shown in Figure 3. The Internet is connected via a VPN channel.
channel.
/\/\/\/\/\ /\/\/\/\/\
\Internet/ \Internet/
/ \ / \
\/\/\/\/\/ \/\/\/\/\/
| |
|150.140.254.110(VPN) |150.140.254.110(VPN)
| |
+------------------------------------+ +------------------------------------+
| LAN | | LAN |
skipping to change at page 11, line 26 skipping to change at page 11, line 26
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE |
|Japan | |China | |Greece| |China | |Greece| |Japan | |Japan | |China | |Greece| |China | |Greece| |Japan |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 4: Scenario for LFB Operation Figure 4: Scenario for LFB Operation
In order to make interoperability more credible,the three In order to make interoperability more credible, the three
implementers are required to carry out the test in a way acting as CE implementers are required to carry out the test in a way acting as CE
or FE alternatively. As a result, every LFB operation is combined or FE alternatively. As a result, every LFB operation is combined
with 6 scenarios, as shown by Figure 4. with 6 scenarios, as shown by Figure 4.
The test scenario is designed with the following purposes: The test scenario is designed with the following purposes:
Firstly, the scenario is designed to verify all kinds of protocol Firstly, the scenario is designed to verify all kinds of protocol
messages with their complex data formats, which are defined in RFC messages with their complex data formats, which are defined in RFC
5810. Specially, we try to verify the data format of a PATH-DATA 5810. Specially, we try to verify the data format of a PATH-DATA
with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array
or an array with a nested array. or an array with a nested array.
Secondly,the scenario is designed to verify the definition of ForCES Secondly, the scenario is designed to verify the definition of ForCES
LFB Library[FORCES-LFBLIB], which defines a base set of ForCES LFB LFB Library[FORCES-LFBLIB], which defines a base set of ForCES LFB
classes for typical router functions. Successful test under this classes for typical router functions. Successful test under this
scenario also means the validity of the LFB definitions. scenario also means the validity of the LFB definitions.
4.2. Scenario 2 - TML with IPSec 4.2. Scenario 2 - TML with IPSec
This scenario is designed to implement a TML with IPSec, which is the This scenario is designed to implement a TML with IPSec, which is the
requirement by RFC 5811. TML with IPSec was not implemented in the requirement by RFC 5811. TML with IPSec was not implemented in the
first ForCES interoperability test as reported by RFC 6053. For this first ForCES interoperability test as reported by RFC 6053. For this
reason, in the second interoperability test, we specifically designed reason, in the second interoperability test, we specifically designed
skipping to change at page 22, line 36 skipping to change at page 22, line 36
| | G | J | | | | Success | | | G | J | | | | Success |
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
Figure 8: LFB Operation Test Results Figure 8: LFB Operation Test Results
Note on test 1#: Note on test 1#:
On the wire format of encapsulation on array, only the case of On the wire format of encapsulation on array, only the case of
FULLDATA-in-FULLDATA was tested. FULLDATA-in-FULLDATA was tested.
In China's implementation,after test 2# CE have to get all LFBs' In China's implementation, after test 2# CE have to get all LFBs'
instance data actively according to the queried component of instance data actively according to the queried component of
LFBSelectors. LFBSelectors.
Note on test 28# and 29#: Note on test 28# and 29#:
Only had new reachable network destination been set,can route entry Only had new reachable network destination been set, can route entry
be added into system. be added into system.
Note on test 30# and 31#: Note on test 30# and 31#:
Corresponding nexthop entry must be deleted before prefix entry which Corresponding nexthop entry must be deleted before prefix entry which
is decided by FE's routing management. is decided by FE's routing management.
5.2. TML with IPSec Test 5.2. TML with IPSec Test
In this scenario, the ForCES TML is run over IPSec. Implementers In this scenario, the ForCES TML is run over IPSec. Implementers
skipping to change at page 25, line 4 skipping to change at page 25, line 4
The test is reported with the results in Figure 10 The test is reported with the results in Figure 10
+-----+----+-----+-------------------------+--------------+---------+ +-----+----+-----+-------------------------+--------------+---------+
|Test#| CE |FE(s)| Item | LFBs Related | Result | |Test#| CE |FE(s)| Item | LFBs Related | Result |
+-----+----+-----+-------------------------+--------------+---------+ +-----+----+-----+-------------------------+--------------+---------+
| 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success | | 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | | | | | | | | |
| 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success | | 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success |
| | | | | | | | | | | | | |
| 3 | J | C |Redirect ospf packet from| RedirectIn | Success | | 3 | J | C |Redirect OSPF packet from| RedirectIn | Success |
| | | | CE to SmartBits | | | | | | | CE to SmartBits | | |
| | | | | | | | | | | | | |
| 4 | J | C |Redirect ospf packet from| RedirectOut | Success | | 4 | J | C |Redirect OSPF packet from| RedirectOut | Success |
| | | | SmartBits to CE | | | | | | | SmartBits to CE | | |
| | | | | | | | | | | | | |
| 5 | J | C | Metadata in | RedirectOut | Success | | 5 | J | C | Metadata in | RedirectOut | Success |
| | | | redirect message | RedirectIn | | | | | | redirect message | RedirectIn | |
| | | | | | | | | | | | | |
| 6 | J | C |OSPF neighbor discovery | RedirectOut | Success | | 6 | J | C | OSPF neighbor discovery | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | | | | | | | | | |
| 7 | J | C | OSPF DD exchange | RedirectOut | Success | | 7 | J | C | OSPF DD exchange | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | | | | | | | | | |
| 8 | J | C | OSPF LSA exchange | RedirectOut | Success | | 8 | J | C | OSPF LSA exchange | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| | | | | | | IPv4UcastLPM| |
| | | | | | | | | | | | | |
| 9 | J | C | Data Forwarding | RedirectOut | Success | | 9 | J | C | Data Forwarding | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| | | | | | | IPv4UcastLPM| |
| | | | | | | | | | | | | |
| 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success | | 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | | | | | | | | |
| 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success | | 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success |
| | | | | | | | | | | | | |
| 12 | C | J |Redirect ospf packet from| RedirectIn | Success | | 12 | C | J |Redirect OSPF packet from| RedirectIn | Success |
| | | | CE to other OSPF router | | | | | | | CE to other OSPF router | | |
| | | | | | | | | | | | | |
| 13 | C | J |Redirect ospf packet from| RedirectOut | Success | | 13 | C | J |Redirect OSPF packet from| RedirectOut | Success |
| | | |other OSPF router to CE | | | | | | |other OSPF router to CE | | |
| | | | | | | | | | | | | |
| 14 | C | J | Metadata in | RedirectOut | Success | | 14 | C | J | Metadata in | RedirectOut | Success |
| | | | redirect message | RedirectIn | | | | | | redirect message | RedirectIn | |
| | | | | | | | | | | | | |
| 15 | C | J |OSPF neighbor discovery | RedirectOut | Success | | 15 | C | J |OSPF neighbor discovery | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | | | | | | | | | |
| 16 | C | J | OSPF DD exchange | RedirectOut | Failure | | 16 | C | J | OSPF DD exchange | RedirectOut | Failure |
| | | | | RedirectIn | | | | | | | RedirectIn | |
skipping to change at page 26, line 12 skipping to change at page 26, line 12
| 17 | C | J | OSPF LSA exchange | RedirectOut | Failure | | 17 | C | J | OSPF LSA exchange | RedirectOut | Failure |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| | | | | | | IPv4UcastLPM| |
+-----+----+-----+-------------------------+--------------+---------+ +-----+----+-----+-------------------------+--------------+---------+
Figure 10: Packet Forwarding Test Results Figure 10: Packet Forwarding Test Results
Note on test 1# and 2#: Note on test 1# and 2#:
Before redirect channel working normally, multicast route pointed to A multicast route pointed to localhost was manually set before
localhost must be added manually firstly. redirect channel could work normally.
Note on test 3# to 9#: Note on test 3# to 9#:
During the tests, ospf packets received from CE were found by During the tests, OSPF packets received from CE were found by
Ethereal/Wireshark with checksum errors. China's FE corrected the Ethereal/Wireshark with checksum errors. China's FE corrected the
checksum in FE so that the Smartbits would not drop the packets and checksum in FE so that the Smartbits would not drop the packets and
the neighbor discovery can continue. Such correcting action does not the neighbor discovery can continue. Such correcting action does not
affect the test scenarios and the results. affect the test scenarios and the results.
Comment on Test #16 and #17: Comment on Test #16 and #17:
The two test items failed. Note that Test #7 and #8 are exactly the The two test items failed. Note that Test #7 and #8 are exactly the
same as these tests, only with CE and FE implementers are exchanged, same as these tests, only with CE and FE implementers are exchanged,
and Test #12 and #13 show the redirect channel works well. As a and Test #12 and #13 show the redirect channel works well. As a
skipping to change at page 28, line 29 skipping to change at page 28, line 29
An array operation may also have several different data encapsulation An array operation may also have several different data encapsulation
formats. For instance, if a CE sends a config message to table 1 formats. For instance, if a CE sends a config message to table 1
with a path of (2.1), which refers to component with ID=2, which is with a path of (2.1), which refers to component with ID=2, which is
an array, and the second ID is the row, so row 1, it may be an array, and the second ID is the row, so row 1, it may be
encapsulated with three formats as below: encapsulated with three formats as below:
format 1: format 1:
OPER = SET-TLV OPER = SET-TLV
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=2.1 IDs=2.1
FULLDATA-TLV conaining valueof(x),valueof(y) FULLDATA-TLV containing valueof(x),valueof(y)
format 2: format 2:
OPER = SET-TLV OPER = SET-TLV
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=2.1 IDs=2.1
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=1 IDs=1
FULLDATA-TLV containing valueof(x) FULLDATA-TLV containing valueof(x)
PATH-DATA-TLV PATH-DATA-TLV
IDs=2 IDs=2
FULLDATA-TLV containing valueof(y) FULLDATA-TLV containing valueof(y)
skipping to change at page 30, line 20 skipping to change at page 30, line 20
Hirofumi Yamazaki Hirofumi Yamazaki
NTT Corporation NTT Corporation
Tokyo Tokyo
Japan Japan
Email: yamazaki.horofumi@lab.ntt.co.jp Email: yamazaki.horofumi@lab.ntt.co.jp
Rong Jin Rong Jin
Zhejiang Gongshang University Zhejiang Gongshang University
Hangzhou Hangzhou
P.R.China P.R.China
Email: jinrong@zjgsu.edu.cn Email: jinrong@zjsu.edu.cn
Yuta Watanabe Yuta Watanabe
NTT Corporation NTT Corporation
Tokyo Tokyo
Japan Japan
Email: yuta.watanabe@ntt-at.co.jp Email: yuta.watanabe@ntt-at.co.jp
Xiaochun Wu Xiaochun Wu
Zhejiang Gongshang University Zhejiang Gongshang University
Hangzhou Hangzhou
P.R.China P.R.China
Email: spring-403@zjgsu.edu.cn Email: spring-403@zjsu.edu.cn
8. Acknowledgements 8. Acknowledgements
The authors would also like thank the following test participants: The authors would also like thank the following test participants:
Chuanhuang Li, Hangzhou BAUD Networks Chuanhuang Li, Hangzhou BAUD Networks
Ligang Dong, Zhejiang Gongshang University Ligang Dong, Zhejiang Gongshang University
Jingjing Zhou, Zhejiang Gongshang Unviersity Jingjing Zhou, Zhejiang Gongshang University
Liaoyuan Ke, Hangzhou BAUD Networks Liaoyuan Ke, Hangzhou BAUD Networks
Kelei Jin,Hangzhou BAUD Networks Kelei Jin, Hangzhou BAUD Networks
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
Developers of ForCES FEs and CEs must take the security Developers of ForCES FEs and CEs must take the security
considerations of the ForCES Framework [RFC3746] and the ForCES considerations of the ForCES Framework [RFC3746] and the ForCES
Protocol [RFC5810] into account. Also, as specified in the security Protocol [RFC5810] into account. Also, as specified in the security
skipping to change at page 34, line 36 skipping to change at page 34, line 36
[Ethereal] [Ethereal]
"Ethereal, also named Wireshark, is a protocol analyzer. "Ethereal, also named Wireshark, is a protocol analyzer.
The specific Ethereal that was used is an updated The specific Ethereal that was used is an updated
Ethereal, by Fenggen Jia, that can analyze and decode the Ethereal, by Fenggen Jia, that can analyze and decode the
ForCES protocol messages", http://www.ietf.org/ ForCES protocol messages", http://www.ietf.org/
mail-archive/web/forces/current/msg03687.html . mail-archive/web/forces/current/msg03687.html .
[I-D.ietf-forces-ceha] [I-D.ietf-forces-ceha]
Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
Intra-NE High Availability", draft-ietf-forces-ceha-04 Intra-NE High Availability", draft-ietf-forces-ceha-05
(work in progress), July 2012. (work in progress), January 2013.
[I-D.ietf-forces-lfb-lib] [I-D.ietf-forces-lfb-lib]
Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "ForCES Logical Function Block (LFB) Library", Halpern, "ForCES Logical Function Block (LFB) Library",
draft-ietf-forces-lfb-lib-09 (work in progress), May 2012. draft-ietf-forces-lfb-lib-10 (work in progress),
January 2013.
[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.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
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.
 End of changes. 26 change blocks. 
42 lines changed or deleted 44 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/