Internet DRAFT - draft-liu-rtgwg-mtu-config-ps
draft-liu-rtgwg-mtu-config-ps
rtgwg Vic. Liu
Internet-Draft China Mobile
Intended status: Informational July 15, 2013
Expires: January 16, 2014
Probelm Statement for MTU Configuration
draft-liu-rtgwg-mtu-config-ps-00
Abstract
This document describes problem statement of MTU configuration IP and
MPLS network along with the test case and result in multi-vendor
network. Necessary considerations and recommendation are also
discussed.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Liu Expires January 16, 2014 [Page 1]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
4.1. ISIS negotiations and configuration . . . . . . . . . . . 3
4.2. MPLS MTU configuration . . . . . . . . . . . . . . . . . 4
5. Test on MTU configuration . . . . . . . . . . . . . . . . . . 4
5.1. Basic test description . . . . . . . . . . . . . . . . . 4
5.2. Test result and analysis . . . . . . . . . . . . . . . . 7
6. Considerations and recommendations . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
MTU for Jumbo frames is needed in practical network, This document
describes a test on MTU configuration based on IS-IS and MPLS
protocol with routers from different vendors. By test of upgrading
MTU from 1500 to 4470 in multi-vendor network, we bring up a problem
statement of MTU configuration that measure ISIS negotiation. With
the discussion, necessary considerations and recommendation are also
discussed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Terminology
Throughout this document, the use of the terms "Provider Edge (PE)
and Customer Edge (CE)" or "PE/CE" will be replaced by "PE" in all
cases except when a network device is a CE when used in the carrier's
carrier model.
3. Requirements
This section briefly describes enterprise customers and operational
requirement on network MTU configuration along with a list of
problems on MTU configuration over multi-vendor equipment.
The MTU default configuration is 1500 in China Mobile backbone
network. However some enterprise customers requested that IP
datagram's up to a length of 1600 bytes (including the IP header,
Liu Expires January 16, 2014 [Page 2]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
aka. baby giant) must not be fragmented in the supplier's network
(from CE to CE). The receiving sequence of data packets at the
destination location must match the sending sequence at the source
location. Besides, from the network operational point of view, TD-
LTE network also has the MTU requirement. As the CE connect to
eNodeB with packet of 1500. It will be jumbo frame in S1-U port(GTP
header will be added). To avoid fragment from CE to CE, it required
MTU to support IP datagrams length of 1600 bytes at least.
In above, we decided to upgrade MTU from 1500 to 4470(same as POS
MTU) in the backbone routers. In the rest of this draft, we are
introduce a multi-vender test on MTU from 1500 to 4470 in IP networks
and MPLS-VPN networks along with problem statement during this
configuration.
4. Problem statement
This section list a number of problems we met during configure MTU
from 1500 to 4470 in IP networks and MPLS-VPN networks with routers
from different vendors.
4.1. ISIS negotiations and configuration
In IP networks, we tested routers from 4 vendors, indicated as A, B,
C and D as the rest of the draft. As all the four router being
configure to 4470. The ISIS protocol status is listed as table 1
below. ISIS negotiation appears 'Init' as MTU being configured to
4470 across 4 routers from different vendors.
+------------+-----------+------------+
| Router 1 | Router 2 | ISIS status|
+------------+-----------+------------+
| A | B | UP |
+------------+-----------+------------+
| B | C | Init |
+------------+-----------+------------+
| C | D | UP |
+------------+-----------+------------+
| D | A | Init |
+------------+-----------+------------+
| B | D | Init |
+------------+-----------+------------+
| A | C | Init |
+------------+-----------+------------+
Table 1 Probelm of ISIS negotiation status
Liu Expires January 16, 2014 [Page 3]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
4.2. MPLS MTU configuration
In MPLS networks, we figure out that the MPLS diagrams should be
calculate to MTU configuration. However, as we configured and add 2
MPLS labels (8 bytes) to MTU in this 4 router. We captured fragments
on some pairs among 4 routers.
5. Test on MTU configuration
This section introduction test on MTU configuration in IP networks
and MPLS networks based on multi-vendor devices.
5.1. Basic test description
This test contain 3 test cases: Fist we configured MTU from 1500 to
4470 in IP network to test ISIS status on 4 routers from different
routers. To reproduce this problem introduced on 3.1. Then, based
on the test result, we establish MPLS network to test how MPLS MTU
cause that problem in 3.2. Finally, we set up a network hybrid with
IP and MPLS to test the performance of MTU configurations. Test
equipment are from 4 different vendors indicated as A, B, C and D in
the following parts of discussion.
TC1: Test of ISIS MTU. The basic topology of ISIS MTU testing can be
depicted as follows.
+---------+ +---------+
| Router1 |-----------| Router2 |
+---------+ 10GE +---------+
| |
10GE | 10GE |
VLAN | VLAN |
Port1 | Port2 |
+---------------------------+
| Tester |
+---------------------------+
Figure 1 Basic topology for ISIS MTU testing
As figure 1 shows, two routers connect with each other by a 10GE
link. Each router connect to the tester by a 10GE link. The tester
generates unidirectional/bidirectional traffic between port 1 and
port 2 with the traffic load of 10G. The frame length generate by
tester is equals to the desired MTU parameter, 4470. We configure
Liu Expires January 16, 2014 [Page 4]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
MTU parameter on router 1 from 1500 to 4470 and check the ISIS
protocol status and then configure the MTU parameter on router 2 from
1500 to 4470 and check ISIS protocol status again to make sure the
ISIS status is up. If ISIS is not up, we increase MTU on one side
until the ISIS status is up. As ISIS is established, we inject the
traffic from the tester and capture the packet on port 1 and port 2
to check if there is a fragment on the packet.
The routers from 4 vendors are being tested as the sequence table
below.
+------------+-----------+
| Router1 | Router2 |
+------------+-----------+
| A | B |
+------------+-----------+
| B | C |
+------------+-----------+
| C | D |
+------------+-----------+
| D | A |
+------------+-----------+
| B | D |
+------------+-----------+
| A | C |
+------------+-----------+
Table 2 TC1 test sequence table
TC2: The test topology of MPLS-VPN test can be depicted as follows.
+---------+ MPLS +---------+ MPLS +---------+
| Router1 |-----------| Router2 |-----------| Router3 |
+---------+ 10GE +---------+ 10GE +---------+
| |
|10GE |10GE
|VLAN |VLAN
| |
| Port1 +---------------------------+ Port2 |
-------| Tester |-------
+---------------------------+
Figure 2 Basic topology for MPLS-VPN MTU testing
Liu Expires January 16, 2014 [Page 5]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
As figure 2 shows, there are 3 routers form 4 different vendors to
build a MPLS network which Router1, Router3 take part as LER, Router
2 as LSR. VLAN are been established between PE and Tester. The
whole network connect by 10GE link as the figure shows. The tester
generates unidirectional/bidirectional traffic between port 1 and
port 2 with the traffic load of 10G. While MTU parameter is set as
the ISIS MTU test of each vendors. And the tester generate traffic
with the packet length of 4474(4474+4 bit VLAN tag). We capture
packet on tester's port1 and port2 to check if there is a fragment
packet. If there is, we increase one of the router's MTU parameter
and capture again.
The routers from 4 vendors are being tested as the sequence table
below.
+------------+-----------+------------+
| Router1 | Router2 | Router3 |
+------------+-----------+------------+
| B | A | C |
+------------+-----------+------------+
| A | B | C |
+------------+-----------+------------+
| B | C | D |
+------------+-----------+------------+
| A | D | D |
+------------+-----------+------------+
Table 3 TC2 test sequence table
TC.3 MTU performance test
This test case mainly test the performance on IP and MPLS networks.
The topology can be depicted as below
VLAN +---------+ MPLS
===========|B:Router1|================
|| IP +---------+ IP ||
|| || ||
|| MPLS || IP ||
|| || ||
|| +---------+ MPLS +---------+
|| |A:Router2|===========|D:Router3|
|| +---------+ IP +---------+
|| || ||
|| MPLS || IP MPLS || IP
|| || ||
Liu Expires January 16, 2014 [Page 6]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
|| +---------+ MPLS +---------+
|| |C:Router4|===========|A:Router5|
|| +---------+ IP +---------+
|| VLAN || IP VLAN || IP
|| Port3||Port4 Port5||Port6
|| Port1 +---------------------------+
============| Tester |
Port2 +---------------------------+
Figure 3 Basic topology for MTU performance test
As figure 3 shows, there are 5 routers to setup 4 vendor network with
both MPLS and IP traffic. Router1, Router4 and Router5 act as PE
while Router2 takes part as RR and Router3 as P. The whole network is
being connect by 10GE links. The Tester connect with PE by two links
while one is for VLAN traffic and other is for IP traffic. PE
connect with RR and P also using two links. One is for MPLS traffic
and other is for IP traffic. All ports on tester generate traffic
load of 10GE with random frame length (minimum 64, MAX is equal to
MTU of PE). The MTU parameter of routers on each port is set as the
result in TC1 and TC2.
This test case is to check the performance of latency and packet
dropping rate with 24 hours.
5.2. Test result and analysis
This section introduce test report of MTU configuration workable in
IP network and MPLS networks.
A. Report of MTU configure in IP network based on multi-vendor
routers. In test case 1, ISIS MTU test. We firstly set all
configure MTU to 4470 and we get the ISIS establish status as this
table below
+---------------------------------------+
| | A | B | C | D |
+-------+-------+-------+-------+-------+
| A | \ | \ | \ | \ |
+-------+-------+-------+-------+-------+
| B | UP | \ | \ | \ |
+-------+-------+-------+-------+-------+
| C | Init | Init | \ | \ |
+-------+-------+-------+-------+-------+
| D | Init | Init | UP | \ |
+-------+-------+-------+-------+-------+
Liu Expires January 16, 2014 [Page 7]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
Table 4 ISIS status with equal MTU
By analyze the IP diagram figure below. We figure out the router of
vendor A and vendor B is being configure based on L3 MTU which means
the MTU parameter equals to L3 diagram length, 4470. And Vendor C
and Vendor D is being configure based on L2 MTU which means the MTU
configure parameter equals to L2 diagram length(without FCS), 4488
|---------------------L2---------------------|
|--------L3--------|
+------------+------+-----------+------+-----+
| Eth Header | VLAN | IP header | Data | FCS |
+------------+------+-----------+------+-----+
Length: 14 | 4 | 20 | 4450 | 4
Figure 4 IP diagram
We find out the minimum MTU configuration parameter that allow ISIS
to establish as the table below:
+--------+---------------+------------+
| Vendor | MTU | Configure |
+--------+---------------+------------+
| A | 4470 | L3 MTU |
+--------+---------------+------------+
| B | 4470 | L3 MTU |
+--------+---------------+------------+
| C | 4484+4(VLAN) | L2 MTU |
+--------+---------------+------------+
| D | 4484+4(VLAN) | L2 MTU |
+--------+---------------+------------+
Table 5 ISIS status with equal MTU
VLAN tag configuration in vendor A and vendor B is not counted in the
MTU configuration. However, in vendor C and vendor D, because of its
L2 MTU, so we have to count every tag in the IP diagram.
B. ISIS MTU negotiation test result between routers from different
vendors.
Liu Expires January 16, 2014 [Page 8]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
As test case 1, we modified the MTU from 1500 to 4470 on one side to
another to test ISIS establish status as the table blow. (With 1
VLAN tag)
+---------+--------+---------+---------+---------+
| | A:4470 | B:4470 | C:4488 | D:4488 |
+---------+--------+---------+---------+---------+
| B:1500 | \ | Init | UP | UP |
+---------+--------+---------+---------+---------+
| B:1500 | Init | \ | UP | UP |
+---------+--------+---------+---------+---------+
| C:1518 | Init | Init | \ | UP |
+---------+--------+---------+---------+---------+
| D:1518 | Init | Init | UP | \ |
+---------+--------+---------+---------+---------+
Table 6 MTU measurement of ISIS UP/Init status
By capture the packet from the ports on the tester and analysis of
this result table, the negotiation method from vendor A and vendor B
is strict to its MTU. However the Vendor C and vendor D is check MTU
with the other side.
C. MTU influence on the MPLS with multi-vendor router. In test case
2, we test MTU configuration on multi-vendor routers in MPLS-VPN
networks. The MPLS diagram can be figure as figure 5
|---------------------L2---------------------|
|--------L3--------|
+------------+------+-----------+------+-----+
| Eth Header | MPLS | IP header | Data | FCS |
+------------+------+-----------+------+-----+
Length: 14 | ? | 20 | 4450 | 4
Figure 5 MPLS diagram
The ? marker can be explained as the MPLS frame length depends on how
many labels used in this network. In our test models, the default
MPLS labels is two(8 bits). As we configure the MTU 4470L3 on Vendor
A and B (4484 L2 on Vendor C and D) on all of the fours router. We
capture the packet from the tester's receiver ports and find
Liu Expires January 16, 2014 [Page 9]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
fragment. As we used two Vendor A's router with one Vendors B's
router to build a MPLS network A-B-A and set the MTU parameter as
4470. There is no fragment. As the MTU is L2 MTU on vendor C and
vendor D. We add two MPLS labels in C's and D's MTU but is still have
fragment. As we increase C's and D's MTU. We get the result as:
+-----+------------+-------------------------------+
| A | 4470+8 | Add 2 MPLS labels |
+-----+------------+-------------------------------+
| B | 4470+8 | Add 2 MPLS labels |
+-----+------------+-------------------------------+
| C | 4484+20 | Default is 5 MPLS labels |
| | | and cannot modify |
+-----+------------+-------------------------------+
| D | 4484+12 | Default is 3 MPLS labels |
| | | and can modify manually |
+-----+------------+-------------------------------+
Table 7 MPLS MTU configuraton of different verndors
6. Considerations and recommendations
In this section, we summarize the analysis and come to the following
considerations:
a.Unified IP MTU negotiations should be taken into consideration. As
we know from the test. The MTU configuration can be divided into two
kinds, some vendor configure MTU based on L2 IP diagram, Vlan tag is
not counted into MTU configuration. However some vendor configure
MTU by L3 diagram which means MTU configuration should count in all
diagram length. That will make confuse multi-vender in networking
operation.
b.Unified MPLS MTU configuration. In MPLS-VPN network, MPLS label
should be calculate in MTU configuration. However, in multi-vendors
networks, there is no standardization to make a unified MPLS MTU
configuration. Vendors such as A and B, It add MPLS labels manually
as configured. Vendor C add 5 fixed labels. Vendor D add 3 fixed
label. If the MPLS label is not unified in MTU configuration, it
will cause fragment in network operation.
c.Unified default MTU negotiation. Vendor A and Vendor B is compare
MTU by a strict mode in MTU negotiation that MTU in both side should
be equal to establish ISIS. However Vendor C and Vendor D compare
Liu Expires January 16, 2014 [Page 10]
Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013
MTU by a loose mode in MTU negotiation that ISIS is established by
Minimum MTU of one side. Although it easier to for MTU negotiation,
it's much easier to cause fragments for multi-vendor networking
operations.
With the consideration above, we summarize recommendations follows:
We test MTU configuration in IP network and MPLS network with routers
from different vendors. The variety forms of MTU configuration
trigger fragment easily in multi-vender networks. However, in order
to make network operation easier, we hope to bring out this problem
statement for all vender to standardize the MTU configuration in IP
network and MPLS network. Meantime, we want to write an operation
guideline to open the test result to declare the problem and guide
others in MTU configurations.
7. Acknowledgements
8. IANA Considerations
The IANA has assigned { mplsStdMIB 11 } to the MPLS-L3VPN-STD-MIB
module specified in [RFC 4362]. This document only makes extensions
to the MPLS-L3VPN-STD-MIB module, there is no further IANA
requirement.
9. Security Considerations
No specific security issues with the proposed solutions are known.
The proposed extension in this document does not introduce any new
security considerations beyond that already apply to the base MPLS/
BGP L3VPN specification as [RFC 3031] and [RFC 4364].
10. Informative References
[RFC1981] McCann, J., "Path MTU Discovery for IP version 6", RFC
1981, August 1996.
[RFC4821] Mathis, M., "Packetization Layer Path MTU Discovery", RFC
4821, March 2007.
Author's Address
Vic Liu
China Mobile
Email: LiuZhiheng@chinamobile.com
Liu Expires January 16, 2014 [Page 11]
