2   Development of the CESNET2 Backbone Network

The development of the CESNET2 network focused in 2005 on the deployment of an optical transport layer based on leased optical fibres and our own transmission technology. The existing technical solution of optical paths equipped primarily with EDFA amplifiers with single-channel transport (so-called grey solution) does not allow for transmission capacity increase on a single optical fibre. It also represents a limiting factor for the provisioning of End-to-End (E2E) services at the level of optical transmission channels. An optical transport layer with a ring topology in the core was created by deploying the DWDM optical transport technology to additional nodes and its integration with the existing path Prague-Brno. The deployed 32-channel ROADM technology (with 10 Gbps individual channel capacity) offers the software-managed on-demand optical channel provisioning. This capability is now available between any two nodes. In the next phase, the implemented DWDM optical transport network will allow for an integration with the existing IP network and for a transition to a hybrid IP/optical backbone based on protocols such as GMPLS, including the implementation of optical switches for dynamic optical path switching.

At the IP/MPLS level we concentrated on upgrading the transport capacity to 10GE by utilising the DWDM network. At the same time, we strove for completing the process of phasing out the core GSR 10216 routers that do not support advanced services such as IPv6 unicast/multicast or jumbo data frames.

We also continued the replacement of obsolete routers with L2/L3 switches in smaller PoPs. These switches are an essential prerequisite for a hybrid IPv4/IPv6 solution, further increase in access capacities, and E2E service provisioning - based on the EoMPLS or VPLS - to the participants that are not directly connected to the DWDM PoPs of CESNET2.

In the area of network protocols we focused in particular on testing and implementing the IPv6 multicast transport in the backbone network.

Deployment of services with a defined QoS level is an integral part of IP network service development. This process requires not only a sound technical implementation but also solving many policy-related problems. We also addressed further development of the supporting infrastructure in order to ensure a robust, resilient and reliable network operation with high availability at both the national and international levels (the latter in cooperation with GÉANT2 and other European NRENs).

One of the important tasks was to prepare our connection to the emerging GÉANT2 network and achieve compatibility and interoperability of all supported network services, mainly in the E2E area. Within the GN2 project that is responsible for GÉANT2, we also participate in the JRA4 activity where we contribute to Work Item 3 that deals with cross-border fibres (CBF).

In 2005, we implemented and/or tested the following modifications and enhancements in the backbone network:

2.1   Physical Topology of the Core Network

Physical network topology (see Figure 2.1) is essentially based on leased optical fibre pairs complying, for the most part, with the ITU-T G.652 recommendation. Several smaller nodes such as Dìèín or Cheb are connected only by a single fibre and utilise the available technologies of Fast Ethernet MRV converters. Remaining nodes are connected to the core by 10 and 34 Mbps radio links, or by leased lines. Depending on the availability of optical fibres in these sites, we will gradually replace these links with optical fibres.

During 2005 we worked on increasing the redundancy of connections of core nodes to optical paths because in many cases parts of the last mile were co-located. In cooperation with providers of optical paths we replaced the co-located paths with independent ones in Prague, Brno, Olomouc and Hradec Králové.

[Figure]

Figure 2.1: Physical topology of the CESNET2 optical backbone network (large image)

Logical topology of the backbone core consists of 11 nodes (GigaPoPs) interconnected by data lines with capacity of at least 1 Gbps (see Figure 2.6). Backbone links use the following technologies: 10GE LAN PHY (10-Gigabit Ethernet), 1GE (Gigabit Ethernet) and POS STM-16/OC-48 (2.5 Gbps). Backbone nodes have in all cases redundant connections to the core.

With respect to equipment for optical lines, we prefer the Nothing in Line (NIL) solution based on placing EDFA amplifiers only at both ends of the optical path. This technology gradually replaces the protocol dependent L2 switches used as repeaters along the line.

We deploy several technologies for optical lines. For shorter gigabit lines (approx. up to 120 km) there is no need for regeneration or amplification, so we use pluggable optical transceivers CWDM-1550 and DWDM GBIC (with channel spacing of 100 GHz according to the ITU-T) at router and switch interfaces.

For optical lines with higher attenuation (above 32 dB) we deploy Keopsys optical EDFA amplifiers (pre-amplifiers and booster amplifiers). However, these amplifiers have several problems such as necessary manual activation after a power failure. Modifications necessary for avoiding this would be costly.

In 2005, we successfully tested the optical amplifier CLA PB01 on the 1 Gbps path Prague-Hradec Králové (150 km, 35.7 dB, G.652). This amplifier has been developed by the Optical networks activity. We used OSA (One Side Amplification) method with a single amplifier and optical filter located in the node Prague.

The test showed that the CLA PB01 amplifier is more suitable and cost-effective than the Keopsys EDFA amplifier. Currently we plan to deploy CLA PB01 amplifiers on the 10 Gbps line that is planned for the optical path Brno-Bratislava (see Figure 2.2).

[Figure]

Figure 2.2: Planned equipment on the optical path Brno-Bratislava (large image)

We propose to use 4-channel multiplexers/demultiplexers that will offer a 10 Gbps optical channel transport capacity. Dispersion will be compensated by means of the Bragg grating that is less expensive than the classical compensators (DCU). The client connections (routers) will be deployed with the DWDM Xenpak or GBIC transceivers for the corresponding wavelength. This path is expected to be deployed at the beginning of 2006.

We also tested 1 Gbps transmissions without amplification on a single optical fibre using passive optical splitters on the path Ostrava-Karviná (76.7 km) (see Figure 2.3).

[Figure]

Figure 2.3: Single-fibre 1GE path between Ostrava and Karviná

The end systems use 1550 and 1590 nm wavelengths.

The DWDM optical transport system was designed as an enhancement to the existing DWDM path Prague-Brno with the goal of achieving a ring topology using ROADM. The requirements on the new system were as follows:

The solution was chosen in a public tender. The winning bid of Cisco Systems is based on the modular DWDM system ONS 15454 MSTP (a detailed description is available at the manufacturer's website www.cisco.com). Their solution is based on the maximum compensation of chromatic dispersion that is close to zero at any section of the ring. This ensures error-free transmission of "colourful" signals. The final structure of deployed optical paths including intermediate nodes is shown in Figure 2.4.

[Figure]

Figure 2.4: Topology of the DWDM optical transport network (large image)

ROADM nodes supporting software-managed optical path add/drop were deployed in PoPs in Prague, Brno, Olomouc and Hradec Králové. ROADM itself consists of an optical switch based on the PLC technology (Planar-Lightwave-Circuit).

The amplifiers and dispersion compensators - located in the intermediate nodes - are needed for ensuring the proper function of DWDM system, required number of transmission channels (32) and quality of the optical channel (BER value). The amplifiers are also based on the ONS 15454 platform.

Two options are available for connecting end systems (users) to DWDM:

  1. By means of transponders that convert the standard "grey" 1310 or 1550 nm signal into a "colourful" DWDM channel via the ITU-T OEO conversion and perform 3R regeneration. Transponders are an integral part of DWDM system and are software-tunable to multiple wavelengths.
  2. Directly to the "colourful" DWDM channel. End user equipment must support a pluggable optical DWDM interface (e.g., Xenpak). This option is cheaper than using transponders but has a number of limitations. Pluggable optical interfaces in routers and switches do not support 3R regeneration, forward error correction and tuning. Therefore, they can be used only on shorter optical paths (maximum 200 km).

After finishing the optical transport system, we were able to upgrade additional core nodes to 10GE (see Figure 2.5). When migrating the backbone to DWDM, we kept the existing ring topology of the backbone network with redundant lines and interconnections between neighbouring nodes. Thanks to the flexibility of DWDM, we will be able to organise the transmission lines into any topology that will best suit the future requirements on the IP/MPLS backbone and services.

[Figure]

Figure 2.5: DWDM transmission system and the IP/MPLS network (large image)

The DWDM optical transport network will also allow to create independent and isolated structures at the lowest level (L1) on the same optical fibre infrastructure.

An important goal for the DWDM system development is to offer lambda services for research projects and advanced network users.

2.2   Logical Topology of the Backbone Network

IP/MPLS is the main transport protocol in the CESNET2 backbone network. We use PSPFv2 as the IGP routing protocol in the MPLS core. Logically, the network is divided into two functional levels and the individual PoPs have been adjusted accordingly (see Figure 2.6):

Smaller network nodes are always connected to the access routers of backbone nodes via low end routers of the C2621/C2651-XM/C2691 series with limited functionality (MPLS CE). These routers are being gradually replaced with access L2/L3 Catalyst 3750G switches that allow gigabit speeds and offer MPLS VPN services.

[Figure]

Figure 2.6: Logical topology of the CESNET2 backbone network (large image)

2.3   IPv4 Unicast

Internal BGPv4 (iBGP) is used as the interior routing protocol for exchanging reachability information between access PE routers. Robustness of the routing system is ensured by means of redundant BGP route reflectors RR1, RR2 and RR3 that are set up on external routers R84, R85 and R98. Other PE routers run as route reflector clients. Figure 2.7 shows the established iBGP sessions only for RR1. The aim of deploying route reflectors was to reduce the number of distinct BGP sessions in the backbone network. Static aggregated blocks are used on the access routers at backbone nodes with no redistribution of interior routing protocol information. Large metropolitan and campus networks (PASNET, CTU etc.) utilise private autonomous systems and are connected to the backbone network using eBGP protocol. For connections of smaller participants we prefer static routes.

[Figure]

Figure 2.7: IPv4 unicast routing via IBGP (only peerings with route reflector RR1 on R84 are shown) (large image)

2.4   IPv4 Multicast

Interior MBGP protocol is used for exchanging multicast routing information. iMBGP information is being distributed by the same route reflectors on R84, R85 and R98 routers as for unicast IBGP. Route reflector clients are - contrary to the unicast routing - configured on all P and PE routers. Core P routers need the iMBGP information in order to be able to perform the RPF (Reverse Path Forwarding) function that protects against routing loops or duplicate multicast packets.

PIMv2-SM protocol has been deployed throughout the backbone network. We reduced the overall multicast routing topology - currently we use only a single central RP (Rendezvous Point) with address 195.113.144.2 on routers R85 a R98 that implement the redundant anycast RP approach. Large metropolitan and campus networks operate their own RPs (within their independent multicast domains) and advertise active sources of multicast data through the MSDP protocol. Smaller connected networks have the option to use the central RP. We no more advertise the RP address through the dynamic protocols (Cisco Auto-RP or BSR), so the it has to be configured statically on all access routers.

Current logical topology of multicast routing is not congruent with the unicast one (unicast packets are MPLS-switched whereas multicast is transported as pure IP). At the MSDP level, the advertised active sources and groups are filtered according to the Cisco and GÉANT recommendations (blocking traffic such as Novell NDS, ImageCast and other multicast services that are not supposed to be advertised to backbone networks).

The CESNET2 backbone network now also supports Source-Specific Multicast that uses reserved IP address block 232.0.0.0/8 and does not require RP for its operation.

An alternative to the traditional multicast address allocation via dynamic protocols such as SDR (SAP), RFC 2770 offers a mechanism for static allocations based on the autonomous system number (AS). Our AS number (2852) corresponds to the public multicast address block 233.11.36.0/24.

2.5   Implementation of IPv6

The CESNET2 backbone network supports hybrid unicast IPv4/IPv6 routing (dual-stack) over MPLS using the PE/6PE technology.

2.5.1   IPv6 Multicast Test Network

As in the IPv4 case, the topologies for unicast and multicast IPv6 data transport are not congruent (multicast bypasses MPLS). Cisco 7500 routers are used for multicast IPv6 routing. These routers are interconnected by means of tunnels into a star topology centred at the R62 router. Due to the lack of a standardised source advertising method, both M6Bone and GÉANT2 networks decided to deploy only a single RP. Recently, the "embedded RP" method is available for this purpose as specified in RFC 3956. Our configuration allows to use both options - static RP and embedded RP. The disadvantage of the latter solution is that the group addresses have to be chosen according to the address of the nearest embedded RP in cooperation with the its administrator.

In order to be able to communicate within the M6Bone network, we had to configure the static RP 2001:660:3007:300:1:: operated by Renater in France. Unfortunately, as this RP runs on the router that is often used for other purposes (training etc.), it frequently becomes unavailable. This is inconvenient despite the fact that the RP outages are always properly announced by Renater.

Global IPv6 multicast connectivity is now provided by the GÉANT2 network. Our connection is currently realised through a tunnel terminated at the R62 router.

In 2006, we plan to configure IPv6 multicast directly on PE routers without using tunnels. Multicast IPv6 routing has been already tested on the PE router (Cisco 7609 OSR) in Liberec with the Technical University of Liberec being connected natively. Later on we plan to deploy an embedded RP that has been extensively tested between Liberec and Ostrava, and also test the MLD2 (Multicast Listener Discovery) protocol in local networks.

2.6   QoS Implementation

We deployed the first phase of priority services for certain traffic classes with guaranteed Quality of Service (QoS). Along with the technical implementation, we had to formulate QoS policy rules for individual users categories.

After finishing necessary pilot tests, we implemented the architecture of a "point-to-cloud", destination-unaware DiffServ domain in the CESNET2 network. We use the E-LSP (Exp-based Label Switched Path) technique over the backbone MPLS infrastructure in the so-called "short pipe" tunnel MPLS mode where the original DSCP value in IP headers is preserved across the MPLS backbone (DSCP transparency).

QoS DiffServ domain of CESNET2 guarantees the operational QoS profile for individual service classes (including minimum guaranteed bandwidth and other qualitative characteristics such as delay, jitter, packet loss) for transit traffic. If the backbone traffic is weak, some QoS classes may utilise extra bandwidth above their minimum guaranteed bandwidth (in proportion to their relative weight). Needless to say, the QoS implementation QoS in CESNET2 complies with Premium IP (PIP) and Less than Best Effort (LBE) services offered by GÉANT network.

Service ClassPHBDSCPExp MPLSBandwidth
Premium IPEFEF, CS5525 %
Network ControlAFCS7, CS67, 61 %
Gold IP+AFAF4x, CS4429 %
Silver IP+AFAF3x, CS3, AF2x, CS23. 214 %
Best EffortDefault0 (other)030 %
LBEAFAF1x, CS111 %

Table 2.1: Proposed PHB, DSCP/Exp mapping and bandwidth reservation for individual QoS classes

Table 2.1 shows the proposed labelling scheme for IP packets with DSCP, its mapping onto the Exp MPLS header subfield and the corresponding bandwidth reservations within the CESNET2 MPLS/DiffServ domain. The proposed values of reserved bandwidth for individual internal backbone paths can be viewed as a starting recommendation that may be modified if necessary based on the operational experience, actual topology of a given network part, and potentially on aggregated user traffic within individual QoS classes as agreed with certain customers. It is required though that the following limits for the router per-hop behaviour be observed:

DSCP and Exp values in MPLS headers were chosen so that they allow to implement the so-called ToS reflection method for mapping the highest three bits of ToS header field directly into the Exp MPLS header subfield. This mapping is performed by routers during IP packet encapsulation into an MPLS frame at the boundary of the MPLS and IP networks.

The proposed policy framework for controlling traffic from/to other DiffServ domains that is entitled to use guaranteed QoS when transiting the CESNET2 backbone is based on the so-called point-to-cloud model that does not take into account the destination address. For each individual ingress (egress) interface from (to) a foreign DiffServ domain to (from) the CESNET2 MPLS/DiffServ domain, the traffic profiles with guaranteed QoS are defined by an SLA. Their enforcement is controlled by policers or shapers (at egress). For a supported QoS class a set of ingress1 and egress2 parameters is defined that determines the behaviour of trTCM (two rate Three Colour Marker) packet marker/limiter. This marker checks the rate of real traffic excess in comparison to agreed traffic profile and possibly performs a necessary corrective action (e.g., reclassification, rejection) for packets belonging to the portion of traffic that violates the agreed traffic profile.

[Figure]

Figure 2.8: Point-to-cloud QoS model with traffic admission control at the domain boundary (large image)

Service ClassConform (t<IBCt) Exceed (IBCt<t<IBEt) Violate (t>IBEt)
Premium IPPremium IPBest EffortBest Effort
Net. controlNetwork ControlBest EffortBest Effort
Gold IP+Gold IP+Best EffortBest Effort
Silver IP+Silver IP+Best EffortBest Effort
Best Effort---
LBE---

Table 2.2: Proposed trivial traffic reclassification and remarking according to contract violation level

Table 2.2 shows a very benevolent proposal for reclassification, remarking of traffic entering the CESNET2 MPLS DiffServ domain and follow-up repressive actions depending on the severity level of a particular violation of the agreed traffic contract in individual classes. The goal is to ensure acceptable handling (typically Best Effort) even for traffic that violates the contract. At the same time, a rule exists for the case when the so-called "higher" QoS classes (Premium IP, Network Control, Gold IP+ and Silver IP+) do not use all the bandwidth allocated them: the remaining capacity may be used by the Best-Effort class and, if there is still any remaining capacity, by the Less-than-Best-Effort class.

Such a relatively trivial QoS policy framework for traffic admission control represents a suitable solution only if it is acceptable that the traffic portion in excess of the contract within the "higher" QoS classes may lead, after having been reclassified into "lower" classes (Best Effort or Less than Best Effort), to a violation of the overall contract of aggregated traffic for all QoS classes. This may happen because the "lower" QoS class traffic is not limited, and only when the total contracted bandwidth for all QoS classes exceeds the physical transmission capacity of an intradomain access line. Otherwise, it would be necessary to apply a hierarchical/two-stage limit when the first limiter performs admission control for all aggregated traffic (without QoS class differentiation) and excess traffic is dropped. In the next stage, the second limited reclassifies the admitted traffic portion with regard to the related QoS classes in accordance to the above-mentioned QoS framework policy. Similarly, the same QoS policy may apply to the traffic that leaves the CESNET2 MPLS DiffServ domain.

A clear advantage of the proposed CESNET2 QoS policy framework is in its simple implementation and administration: each QoS/DiffServ neighbour domain is responsible for a reliable allocation of "its" traffic to the QoS classes and there is no need for maintaining any other information about "trusted" sources, such as lists of allowed IP addresses. The only potential exception is the Network Control class that is typically used for internal transmission of priority network control information within the CESNET2 MPLS/DiffServ domain. In some cases, this class may be useful to support even between different DiffServ domains (e.g., for guaranteed transmission of some routing information). This class should then be configured using an ingress access list allowing only enumerated trusted sources in foreign QoS domains so that the security risks are reduced.

At the same time, an appropriate implementation of ingress (or egress) reclassifiers/limiters may allow for an easy reaction to a violation of agreed traffic interdomain QoS contracts.

The technical implementation of PHB in Cisco routers depends heavily on their type (and the type/version of installed modules). We thus decided to deploy a unified PHB implementation for both IP and MPLS: we use the LLQ queueing technique for EF PHB and CBWFQ for AF PHB. These techniques are both recommended by the manufacturer for these purposes and supported by virtually all routers we use: Cisco 7600 with OSM modules, Cisco 7500 and Cisco 7200. Only Cisco 7600 LAN modules do not support these techniques, so they had to be replaced by appropriately parametrised WRR techniques with a priority queue. WRED configuration is implemented on those devices and modules that support it.

Traffic admission control according to individual QoS classes is performed exclusively at the boundary of the CESNET2 MPLS/DiffServ domain on PE-CE interfaces in accordance with the destination-unaware point-to-cloud model. However, it is questionable whether it is reasonable to perform traffic limiting also at the egress of the CESNET2 MPLS/DiffServ domain because the traffic that violated the QoS contract had already transited the CESNET2 backbone. Thus the only reason for such a traffic reclassification/remarking might be the enforcement of a QoS contract with a neighbour DiffServ domain.

[Figure]

Figure 2.9: QoS interface types in the CESNET2 MPLS/DiffServ domain (large image)

Figure 2.9 shows QoS interfaces of P, PE and CE routers in the CESNET2 MPLS/DiffServ domain where suitable techniques for guaranteeing QoS and for traffic admission control may be implemented. Currently, these are configured as follows:

2.7   Backbone Network Security

For securing the core routers, we implemented CoPP (Control Plane Policing) that reduces the possibility of intrusions and helps to protect the router against DoS attacks.

CoPP allows to configure QoS access lists for traffic control. The router processor is protected from getting overloaded by limiting the traffic passing through the processor itself.

We defined five main classes  - see table 2.3.

PurposeProtocols
1.interior routingOSPF, iBGP, PIM, MSDP, IGMP
2.exterior routingeBGP, PIM, IGMP, SAP
3.network managementTelnet, SSH, SNMP, TFTP, NTP, TACACS+, DNS
4.availability testingICMP echo (ping, traceroute)
5.undesirable trafficforbids all undesirable traffic
(ICMP, TCP, UDP, IP, OSPF, ...)

Table 2.3: Proposed CoPP classes

We started by determining the bandwidth for allowed traffic in the first three classes. The excess traffic has been (temporarily) allowed. In the fourth class we dropped the excess traffic and in the fifth class we blocked all traffic. We periodically monitor and evaluate all traffic, filters, and QoS settings. Especially in the beginning, the bandwidth was changed several times. The implementation was applied stepwise to all nodes and eventually also to edge routers.

During the testing period, we found out that some network monitoring tools utilise mainly ping (ICMP echo/echo-reply). After CoPP has been implemented, these tools reported connectivity problems. This again illustrates the fact that majority of users equate the network availability with timely responses from the ping or traceroute commands.

Another rather marginal problem was the IP addressing within the backbone network. Our network was built in several phases and so some of its parts use inconsistent addressing rules and/or ranges. Due to this fact, the access lists defining rules for individual class are longer than necessary. We are thus considering options for renumbering internal addresses in the entire backbone network.

2.8   External Connectivity

CESNET2 network has the following external connections and peerings:

[Figure]

Figure 2.10: External connectivity of the CESNET2 network (large image)

International connectivity for commodity traffic

Global connection is provided by Telia International Carrier. The link capacity is 2.5 Gbps (POS STM-16/OC-48 on R84) with a limit of 800 Mbps. Another 2.5 Gbps line is used as a backup connection to a second Telia router (our peering router is R85).

Connection to the GÉANT2 network

GÉANT2 network is oriented on providing E2E services with guaranteed quality. Its architecture is based on a combination of a routed IP network and a switched DWDM transport network. Ethernet/SDH switches mapping Ethernet onto SDH using GFP-F/VCAT/LCAS encapsulation offer higher flexibility to the Ethernet services at L2. CESNET2 network will have two types of connections: standard IP and a connection to an Ethernet/SDH switch for E2E service provisioning (see Figure 2.11). For E2E connections, 10GE technology is planned with 802.1Q VLAN support for aggregating individual data flows. In the first phase, the E2E-oriented access will offer 4×1GE, later on it will be upgraded to the planned capacity. E2E service provisioning will start in 2006 (after GÉANT2 becomes fully operational). The IP connection is already functional (denoted as "Primary IP" in Figure 2.11.

[Figure]

Figure 2.11: GÉANT2 PoP in Prague and its interconnection with CESNET2 (large image)

National peering in NIX.CZ

Access to NIX.CZ is provided by two 10GE LAN PHY links terminated at the external routers R84 and R85. These links use leased optical fibres. Peering is performed at IPv4/IPv6 level. Two independent connections allow for load balancing and mutual backup.

Peering with SANET, PIONIER and ACOnet networks

Interconnection with Slovak academic network SANET is realised through optical fibres Brno-Bratislava. The path is deployed with CWDM-GBIC-1550 and a Catalyst 3524 switch is used as a repeater. The connection to the Polish academic network is also based on optical fibres between Ostrava and Bialsko-Biala with CWDM-GBIC-1550. This path is shorter, approximately 120 km, and so the optical signal need not be amplified there.

On both international connections we use the 802.1Q encapsulation. We use a dedicated VLAN for connecting to the Austrian ACOnet network through SANET.

Apart from the mutual BGP peering, this connection is used by SANET for accessing NIX.CZ and, conversely, by CESNET2 for accessing the Slovak SIX peering centre. This reduces the demands on international connectivity on both sides. On a mutual basis, reachable networks advertised to the foreign peering centre are tagged with BGP communities. ACOnet network also offers peering in the Austrian peering centre VIX.

The existing capacity of these connections (1 Gbps) is insufficient. For this reason, it is impossible e.g., to allow the PIONIER network access to VIX. An upgrade of the Brno-Bratislava link to 10 Gbps is being prepared. It will be deployed with our own optical amplifier CLA PB01 (see Figure 2.2).

2.9   Plans for the Backbone Network

Future development of all CESNET2 network layers will address E2E service provisioning and ensuring interoperability with the GÉANT2 network. As an integral part of E2E services, we will investigate and test integration of IP/MPLS with the optical transport layer that should enable simpler mechanisms for E2E transport channels provisioning, monitoring and troubleshooting. At the optical transport layer, we will further extend the DWDM backbone in order to be able to offer lambda services in all major PoPs of the CESNET2 network. An integral part of the DWDM deployment is the connection of new paths to the main DWDM ring that will allow for automatic provisioning of optical transport channels.

At the IP/MPLS layer, we will focus on implementing new protocols and capabilities such as IPv6 multicast and VPLS. At the same time, we will continue the process of upgrading PoPs to 10GE will. For this upgrade, we will use in part the DWDM optical transport layer and in part a simpler and cheaper deployment of CLA PB01 on their optical access links (in PoPs where DWDM connection is not planned).

[Figure]

Figure 2.12: Extensions of the DWDM network planned for 2006 (large image)

Planned optical network topology is shown in Figure 2.12.

Individual activities can be summarised as follows:

Development of the DWDM optical transport network

Development of the IP/MPLS network layer

 

Footnotes:

  1. Ingress Committed Rate: ICRclass, Ingress Peek Rate: IPRclass, Ingress Burst Conform: IBCclass, Ingress Burst Exceed: IBEclass

  2. Egress Committed Rate: ECRclass, Egress Peek Rate: EPRclass, Egress Burst Conform: EBCclass, Egress Burst Exceed: EBEclass

previous
contents 		next
metacentrum elearning liberouter live shows videoserver eduroam