Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
OCN Experience to Handle the
Internet Growth and the...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
22
Background
•  Internet traffic / full routes are ...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Agenda
1. Current situation of Internet traffic
in J...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Internet Traffic Trend in Japan
2004 2005 2006 2007 ...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
55
•  The number of broadband subscribers and the tr...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Internet Full Routes Trend
•  Internet full routes g...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Overview
•  Internet traffic in Japan / full routes ...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Agenda
1. Current situation of Internet traffic
in J...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Houston
US Backbone
Equinix Ashburn
PARIX
ntt.net(...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Gunma
Tokyo
Tokyo West
Osaka
Aichi
Hokkaido
Miyagi
C...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Agenda
1. Current situation of Internet traffic
in J...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
The issues we are facing
1. Routes Growth
Scalabilit...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
FIB table of OCN
•  FIB(Forwarding Information Base)...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Scalability of Router Forwarding Tables
•  When a r...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
•  We were facing a problem:
-  OSPF neighbor went d...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
16
•  What happened?
router
A
router
B
member-li...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
•  Hierarchical FIB
- Cisco: BGP Prefix Independent ...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Agenda
1. Current situation of Internet traffic
in J...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Bandwidth History of OCN
19
2200
5800
17000
Mar 2003...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
A lot of Link Aggregation in OCN
•  A large number o...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Link Aggregation Issues
A)  Traffic load-balancing i...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
A) Traffic load-balancing issues: Background
•  Con...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 23
A) Traffic load-balancing issues
•  Issue 1: Tra...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
24
•  Issue 2: Limited number of hash elements
–  Du...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
•  cf. Difference in traffic load-balance by # of ha...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
26
•  Issue 3: Combination of ECMPs (Equal Cost Mult...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
•  Issue 3: Combination of ECMPs and LAGs
•  Case 2:...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
•  Issue 3: Combination of ECMPs and LAGs
•  Case 3:...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
29
•  Consideration 1:
–  In the case of silent-fai...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
30
•  Consideration 2:
–  Switching policy of LAG-I...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
31
•  Consideration 3:
– Ping for test
•  Packet goe...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
32
•  Limitations on # of links in a LAG
•  Issues o...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Agenda
1. Current situation of Internet traffic
in J...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
OCN Osaka
OCN Aichi
OCN Kyoto
OCN Hyogo
OCN Hiroshim...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
35
Expectation for 100GE
•  Need 100GE I/Fs
–  Band...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
100GE Joint Interoperability Test at JPNAP
36
•  Br...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
Summary
•  The traffic in Japan and BGP table has be...
Copyright © 2011 NTT Communications Corporation. All Rights Reserved.
38
of 38

NANOG52 - OCN Experience to Handle the Internet Growth and the Future

NANOG52 - OCN Experience to Handle the Internet Growth and the Future
Published on: Mar 3, 2016
Published in: Internet      
Source: www.slideshare.net


Transcripts - NANOG52 - OCN Experience to Handle the Internet Growth and the Future

  • 1. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. OCN Experience to Handle the Internet Growth and the Future Takeshi Tomochika <takeshi.tomochika(at)ntt.com> Chika Yoshimura <chika.yoshimura(at)ntt.com> NTT Communications, OCN 1
  • 2. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 22 Background •  Internet traffic / full routes are growing more and more •  One of the most important missions of ISPs -  to carry the traffic with stability and without any congestion •  Making the backbone robust •  We will talk about: -  current traffic situation in Japan -  issues at OCN when designing the backbone network -  future visions
  • 3. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Agenda 1. Current situation of Internet traffic in Japan 2. What is OCN? 3. Current issues we are facing •  Router Forwarding Table •  Link Aggregation 4. Future Plan 33
  • 4. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Internet Traffic Trend in Japan 2004 2005 2006 2007 2008 2009 2010 Download Upload 25.4 % 5.0 % 4 source: Internet Traffic Trends in Japan ( Ministry of Internal Affairs and Communications ) http://www.soumu.go.jp/menu_news/s-news/01kiban04_01000006.html (Japanese) •  Total amount of broadband traffic is 1.7Tbps (Download) - 25.4% growth compared to last year •  Upload traffic decreased over the last year (896Gbps) Total Amount of Traffic (Average) (Gbps)
  • 5. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 55 •  The number of broadband subscribers and the traffic volume per subscriber are growing Internet Traffic Trend in Japan (cont.) (subscribers x 1000) source: Internet Traffic Trends in Japan ( Ministry of Internal Affairs and Communications ) http://www.soumu.go.jp/menu_news/s-news/01kiban04_01000006.html (Japanese) The number of broadband subscribers in Japan : 33,907,000 in Nov 2010 The download traffic per subscriber : 50kbps in Nov 2010 The upload traffic per subscriber : 26kbps in Nov 2010
  • 6. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Internet Full Routes Trend •  Internet full routes growing source: BGPmon http://bgpmon.net/stat.php The number of IPv4 prefix : over 330,000 in June 2011 The number of IPv6 prefix : over 6,000 in June 2011
  • 7. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Overview •  Internet traffic in Japan / full routes have been growing consistently •  Traffic will keep rising in the future - ISPs have to … •  design a robust backbone network to deal with the situation •  The backbone we have been making •  The bandwidth we have 7
  • 8. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Agenda 1. Current situation of Internet traffic in Japan 2. What is OCN? 3. Current issues we are facing •  Router Forwarding Table •  Link Aggregation 4. Future Plan 88
  • 9. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Houston US Backbone Equinix Ashburn PARIX ntt.net(AS2914) OCN Aichi OCN Kyoto OCN Osaka OCN Hyogo OCN Hiroshima OCN Fukuoka OCN Hokkaido OCN Kanagawa OCN Miyagi OCN Chiba OCN Tokyo OCN Tokyo west 180 Gbps 20 Gbps 20 Gbps 480 Gbps 20 Gbps 80 Gbps 120 Gbps 60 Gbps 1Gbps NSPIXP-3 40Gbps JPNAP Osaka 90Gbps JPNAP 10Gbps dix-ie IX Osaka GW 1Gbps Internet Multifeed ICP 20 Gbps 100 Gbps 440 Gbps 20 Gbps OCN(AS4713) 400 Gbps Osaka Core 200 Gbps Aichi Core Gunma Core Tokyo Core Tokyo GW ESPANIX Australia New York Chicago Philippines EUROPE Backbone AMSIX Warsaw DE-CIX Seattle Korea ASIA Backbone PAIX Equinix San Jose Equinix Dallas Miami Atlanta Geneva Frankfurt Dusseldorf Madrid Taiwan Equinix Chicago Osaka Hong Kong 210 Gbps Los Angeles Dallas San Jose Amsterdam Indonesia Singapore LINX London Paris FREEIX Tokyo 280 Gbps Washington D.C. Myanmar Malaysia Sri Lanka NTT Communications’ IP Backbone Network (ntt.net & OCN) May 2011 200 Gbps 200 Gbps 200 Gbps 460 Gbps
  • 10. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Gunma Tokyo Tokyo West Osaka Aichi Hokkaido Miyagi Chiba Kanagawa Kyoto Hyogo Hiroshima Fukuoka Regional POP Core POP Network Design Policy of OCN Full redundant network 100% Traffic Relief More than 100km distance between Core-POPs minimize impact of the disasters Disaster Tolerance No single point of failure Double bandwidth of the peak traffic for every line
  • 11. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Agenda 1. Current situation of Internet traffic in Japan 2. What is OCN? 3. Current issues we are facing •  Router Forwarding Table •  Link Aggregation 4. Future Plan 1111
  • 12. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. The issues we are facing 1. Routes Growth Scalability of Router Forwarding Tables 2. Traffic Growth Link Aggregation
  • 13. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. FIB table of OCN •  FIB(Forwarding Information Base) table has been growing - 410,000 routes in OCN (June 2011) • Causes of growing FIB 1. BGP full routes 2. Prefixes with no-export (several tens of thousands in OCN) 3. ECMP, {i, e} bgp-multipath
  • 14. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Scalability of Router Forwarding Tables •  When a rerouting event occurs, potentially thousands of routes must be updated •  It took a lot of time to converge the routes - When some member-links of a link aggregation were taken down FIB of router-A prefix output interface(s) 10.1.0.0/16 IF-1 IF-2 LAG-3(IF-4, 5) 10.2.0.0/16 IF-1 IF-2 LAG-3(IF-4, 5) IF-1 10.1/16 10.2/16… LAG-3 (IF-4,5) IF-2 router A a certain router FIB table(IPv4) Convergence time (flattened FIB) 360,000 more than 130sec 500,000 more than 210sec router B router C router D × ×
  • 15. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. •  We were facing a problem: -  OSPF neighbor went down due to FIB table convergence •  Between router A and B - Link Aggregation (LAG) had been enabled (minimum-links = 1) - OSPF neighbor had been connected through the LAG interface •  When all member-links but one had been disabled - We had expected the OSPF neighbor to remain up 15 router A router B member-link 1 Link Aggregation member-link 2(down) member-link 3(down) member-link 4 (down) member-link 5 (down) member-link 6 (down) Scalability of Router Forwarding Tables OSPF neighbor went down
  • 16. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 16 •  What happened? router A router B member-link 1 Link Aggregation Interface member-link 2 member-link 3 member-link 4 member-link 5 member-link 6 ×disable (1) Router A detected the interfaces were down (2) Router A started updating FIB (3) Router A finished updating FIB (4) Router A chose another interface to send OSPF hello OSPF hello more than OSPF dead- timer Router-A could not send any OSPF hello packets during (1) – (3), then the neighbor went down Scalability of Router Forwarding Tables OSPF hello
  • 17. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. •  Hierarchical FIB - Cisco: BGP Prefix Independent Convergence(PIC) -  Juniper: indirect-nexthop For more information: BGP Convergence in much less than a second http://www.nanog.org/meetings/nanog40/presentations/ClarenceFilsfils-BGP.pdf •  Fewer routes to be updated •  Improving the route convergence time Scalability of Router Forwarding Tables 17 a certain router FIB table(IPv4) Convergence time (flattened FIB) Convergence time (hierarchical FIB) 500,000 more than 210sec around 25sec
  • 18. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Agenda 1. Current situation of Internet traffic in Japan 2. What is OCN? 3. Current issues we are facing •  Router Forwarding Table •  Link Aggregation 4. Future Plan 1818
  • 19. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Bandwidth History of OCN 19 2200 5800 17000 Mar 2003 installed 10G-IF in the backbone Dec 1996 Started OCN
  • 20. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. A lot of Link Aggregation in OCN •  A large number of 10GE Interfaces •  A lot of Link Aggregation 10GE Interfaces in the backbone 20 OCN Aichi OCN Kyoto OCN Osaka OCN Hyogo OCN Hiroshima OCN Fukuoka OCN Hokkaido OCN Kanagawa OCN Miyagi OCN Chiba OCN Tokyo OCN Tokyo west 180 Gbps 20 Gbps 20 Gbps 480 Gbps 20 Gbps 80 Gbps 120 Gbps 60 Gbps 1Gbps NSPIXP-3 40Gbps JPNAP Osaka 90Gbps JPNAP 10Gbps dix-ie IX Osaka GW 1Gbps Internet Multifeed ICP 20 Gbps 100 Gbps 440 Gbps 20 Gbps OCN (AS4713) 400 Gbps Osaka Core 200 Gbps Aichi Core Gunma Core Tokyo Core Tokyo GW 200 Gbps 200 Gbps 200 Gbps 460 Gbps
  • 21. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Link Aggregation Issues A)  Traffic load-balancing issues (Traffic Polarization) •  Background 1.  Traffic-unbalance by variation of flow - may skip - 2.  Limited number of hash elements 3.  Combination of ECMPs and LAGs   Case 1: ECMP and LAG at the same Node   Case 2: ECMP and LAG at different Node   Case 3: ECMP and ECMP at different Node B)  Operational Considerations 1.  LACP - might skip - 2.  minimum-links - may skip - 3.  Ping to each physical interface C)  Other issues 21
  • 22. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. A) Traffic load-balancing issues: Background •  Condition of traffic load-balancing method in the LAG –  Can’t use per-packet round-robin •  Simple round-robin bring about packet reordering in a flow •  Should use flow-based traffic load-balancing method •  Hash value is used for flow-based traffic load-balance •  Hashing algorithm: calculate the hash value based on the packet information (IP address, MAC address, and etc.) to decide Output I/F IP MACPayload to LAG-A calculate the hash hash=1 → Out I/F=e1 hash=2 → Out I/F=e2 ・・・・・・ LAG-A 22
  • 23. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 23 A) Traffic load-balancing issues •  Issue 1: Traffic-unbalance by variation of flow –  Each flow has each size –  Small issue •  Each 10Gbps physical link has a huge number of flows 4 links Packet Flow Packet LAG Skip this slide due to limited time
  • 24. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 24 •  Issue 2: Limited number of hash elements –  Due to this, traffic cannot be evenly distributed  Less effective use of bandwidth –  The less # of hash elements, the worse traffic balance 5 link 10GE LAG 4 link 10GE LAG 3 link LAG IF#1 H1、H6 IF#2 H2、H7 IF#3 H3、H8 IF#4 H4 IF#5 H5 IF#1 H1、H5 IF#2 H2、H6 IF#3 H3、H7 IF#4 H4、H8 IF#1 H1、H4、H7 IF#2 H2、H5、H8 IF#3 H3、H6 2:2:2:1:1 10+10+10+10*1/2+10 *1/2 = 40 2:2:2:2 10+10+10+10=40 3:3:2 10+10+10*2/3 = 26.7 e.g.: Traffic balance in a LAG when # of hash elements is 8 Use only 40G / 50G <- Traffic balance ratio <- Effective bandwidth in the LAG Use only 27G / 30G A) Traffic load-balancing issues
  • 25. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. •  cf. Difference in traffic load-balance by # of hash elements 5  links  LAG   4  links  LAG   3  links  LAG   IF#1 H1,H6   IF#2 H2,H7   IF#3 H3,H8   IF#4 H4   IF#5 H5   IF#1 H1,H5   IF#2 H2,H6   IF#3 H3,H7   IF#4 H4,H8   IF#1 H1,H4,H7   IF#2 H2,H5,H8   IF#3 H3,H6   40 40 26.7 5  links  LAG   4  links  LAG   3  links  LAG   IF#1 H1,H6,・・・H26,H31   IF#2 H2,H7,・・・H27,H32   IF#3 H3,H8,・・・H28   IF#4 H4,H9,・・・H29   IF#5 H5,H10,・・・H30   IF#1 H1,H5,・・・H29   IF#2 H2,H6,・・・H30   IF#3 H3,H7,・・・H31   IF#4 H4,H8,・・・H32   IF#1 H1,H4,・・・H28,H31   IF#2 H2,H5,・・・H29,H32   IF#3 H3,H6,・・・H30   7:7:6:6:6 10+10+10*6/7+10*6/7+ 10*6/7 = 45.7 8:8:8:8 10+10+10+10  = 40 11:11:10 10+10+10*10/11 = 29.1 The more # of hash elements, the better traffic balance e.g.1: Traffic balance in a LAG when # of hash elements is 8 e.g.2: Traffic balance in a LAG when # of hash elements is 32 25 A) Traffic load-balancing issues Should avoid odd number of member-links in a LAG
  • 26. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 26 •  Issue 3: Combination of ECMPs (Equal Cost Multi Path) and LAGs •  Case 1: –  When hash calculation logic of LAG is the same as ECMP’s, it will bring about unbalanced traffic in physical links LAG1 LAG2 unbalance in LAG 1 flow 1 flow 2 flow 3 flow 4 A) Traffic load-balancing issues no traffic Node 1 physical link 1 physical link 2 flow 1 flow 2 same logic hash calc. for LAG hash calc. for ECMP   flow 3 flow 4 no traffic unbalance in LAG 2 physical link 3 physical link 4• Have to be careful to avoid this • Some routers have the same calculation logics for ECMP and LAG as a default
  • 27. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. •  Issue 3: Combination of ECMPs and LAGs •  Case 2: –  When calculation logic of ECMP is the same as that of next node, it will bring about unbalanced traffic 27 hash calc. for ECMP (a)   hash calc. for ECMP (a) hash calc. for LAG (b) *change* same logic unbalanced ECMP flow 1 flow 2 no traffic no traffic flow 1 flow 2 flow 3 flow 4 A) Traffic load-balancing issues Node 1 Node 2 Need to pay attention to not only Node 1 but also Node 2 LAG3 LAG4 LAG1 LAG2
  • 28. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. •  Issue 3: Combination of ECMPs and LAGs •  Case 3: –  When calculation logic of ECMP is the same as that of LAG at the next node, it will bring about unbalanced traffic 28 LAG3 hash calc. for ECMP (a) hash calc. for ECMP (c) same logic calc. for LAG (b) unbalance in LAG3 calc. for LAG (a) *change* Need to consider balance logics, network topology, configurations flow 1 flow 2 unbalance in LAG4 flow 5 no traffic no traffic flow 1 flow 2 flow 3 flow 4 flow 5 * Some latest routers can include a router-ID in the seed of hash to avoid case 2,3 A) Traffic load-balancing issues Node 1 Node 2 LAG4 LAG1 LAG2
  • 29. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 29 •  Consideration 1: –  In the case of silent-failure, traffic through the fault link will drop LACP (Link Aggregation Control Protocol) ・Send and receive control frames in physical links ・Attention to detail Interoperability - Basically good - Different default mode (fast / slow) - Different reaction to null ID (bug) LACP (keep down / once down then go up) BFD Per Member Link (Bidirectional Forwarding Detection) transmission device B) Operational Considerations Router / SW LAG-I/F Router / SW Might skip this slide due to limited time
  • 30. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 30 •  Consideration 2: –  Switching policy of LAG-I/F •  minimum-link (trunk-threshold) •  threshold whether LAG-I/F is up or down •  This switching policy is important for effective use of LAG •  should consider the entire network topology to use minimum-links e.g.: minimum-link when the policy is 70% in LAG (1)Normally, packets are forwarded to all the link-up I/Fs (3) LAG I/F goes down, and traffic move minimum-link = 3 # of links in LAG 3 4 5 6 7 8 9 10 minimum-link 3 3 4 5 5 6 7 7 LAG LAG (2) still LAG is up, as # of up-links is not less than 3 B) Operational Considerations May skip this slide due to limited time
  • 31. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 31 •  Consideration 3: – Ping for test •  Packet goes through only one physical interface •  Need to test each interface with letting the rest go down •  Some recent routers and switches support Ethernet OAM to avoid this troublesome job B) Operational Considerations
  • 32. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 32 •  Limitations on # of links in a LAG •  Issues of physical wiring –  Increased # of physical links  -> Complicated maintenance   •  Need a well-thought-out plan for LAG –  How to assign physical links to Line Cards •  Redundant policy •  MTBF for each part •  Cost, etc. –  e.g. Policy 1: keep LAG-I/F up as much as possible •  assign each physical link to each LC, minimum-link = 1 –  e.g. Policy 2: Switching traffic to the other LAG immediately •  assign all physical links to one LC, minimum-link = # of links –  e.g. Policy 3: Between policy 1 and policy 2 •  LAG is troublesome –  many LAGs, many member-links NOTE: this is NOT NTT Communications’ equipment C) Other Issues
  • 33. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Agenda 1. Current situation of Internet traffic in Japan 2. What is OCN? 3. Current issues we are facing 4. Future Plan 33
  • 34. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. OCN Osaka OCN Aichi OCN Kyoto OCN Hyogo OCN Hiroshima OCN Hokkaido OCN Miyagi OCN Chiba OCN Tokyo OCN Tokyo west 1600 Gbps 460 Gbps 20 Gbps 20 Gbps 180 Gbps Osaka GW 20 Gbps 280 Gbps 1600 Gbps 20 Gbps Osaka Core 700 Gbps Aichi Core 700 Gbps Gunma Core Tokyo Core 700 Gbps 700 Gbps Tokyo GW OCN Backbone 220 Gbps Osaka Metro-SW Tokyo Metro-SW 1200 Gbps 1200 Gbps OCN future plan 34 OCN Kanagawa 20 Gbps OCN Fukuoka 400 Gbps •  More bandwidth
  • 35. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 35 Expectation for 100GE •  Need 100GE I/Fs –  Bandwidth over 1Tbps –  LAG is troublesome •  Request –  Lower price •  CFP is expensive •  10 x10 MSA (LR10) –  Long-distance transmission (ER4) –  Higher Capacity •  Capacity per chassis will be decreased when migrating from 10GEs to 100GEs in some current routers –  LAG of 10GE and 100GE simultaneously –  good Interoperability, easy-operation 100GE LAG, convenient Ether OAM –  Next step: 400GE, 1T Ether
  • 36. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 100GE Joint Interoperability Test at JPNAP 36 •  Brocade, Cisco, Juniper and Toyo Corporation (Spirent) •  JPNAP, IIJ, and NTT Communications •  Success of 100 Gigabit Ethernet joint interoperability test at IX •  Confirmed the interoperability between different vendors' products especially at an IX environment -  Good interoperability -  Some small issues with each product -  feedback to vendors with some requests •  Further information is available at: http://www.mfeed.co.jp/english/press/2011/20110601-e.html
  • 37. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. Summary •  The traffic in Japan and BGP table has been consistently growing •  We need to consider growth of both routes and traffic to keep our backbone stable •  LAG is troublesome •  We need 100GE to deal with the traffic growth 37
  • 38. Copyright © 2011 NTT Communications Corporation. All Rights Reserved. 38

Related Documents