1. DEVELOPMENTS IN GÉANT2: END-TO-END SERVICES
Roberto Sabatino - DANTE
I2 fall meeting
4 December 2006

2. Agenda GÉANT2 briefing and developments
End to end services and the hybrid infrastructure
GÉANT2 activity JRA3 (BoD) introduction
Monitoring

3. GÉANT2 Some New Facts & Figures… 25 POPs (+4) serve >30 NRENs
Connect. Communicate. Collaborate
GÉANT2
Some New Facts & Figures…
25 POPs (+4) serve >30 NRENs
11600 km of fibre ILA sites
50+ x (own) 10G lambdas
9 x (leased) 10G lambda
8 x 2.5G (leased) “lambda” + some lower speed links
Juniper T640, M160, M40 routers
NREN accesses at up to 10Gbps (+ backup) + P2P
4 x 10G to North America
POP in NY
connections to other R&E networks as before : Abilene, ESnet, CA*net4, SINET, TENET, RedCLARA, EUMEDCONNECT, TEIN2

4. The GÉANT2 fibre topology
Core fibre topology (initial)
Figures in circles represents the number of lambdas
Valid at
July 2006

5. Agenda GEANT2 status and developments
End to end services and the hybrid infrastructure
JRA3 introduction
Monitoring

6. Services over GÉANT2 Point-to-point GE (GE access) GÉANT2
Connect. Communicate. Collaborate
Services over GÉANT2
Point-to-point GE (GE access)
POP C
POP A
Essentially an
implementation of
ITU-T G
EPL service
Type 1
GÉANT2
POP D
POP B
Features:
uses GFP/VCAT
GE port per instance
more dynamic
sub 1G possible

7. Services over GÉANT2 Point-to-point GE (10GE access) GÉANT2
Connect. Communicate. Collaborate
Services over GÉANT2
Point-to-point GE (10GE access)
POP C
POP A
VLAN X
VLAN Y
Essentially an
implementation of
ITU-T G
EVPL service
Type 1
GÉANT2
POP D
POP B
This flavour is not quite ready yet. The 10GE boards (with the EVPL functionality) for the MCCs are deployed but the management software is lagging – this is expected to be resolved by week 43 (end Oct). Also, dot1Q VLAN tags can be swapped* by the 10GE board (when in EVPL mode) but can’t be pushed/popped (although this capability will be available from March 2007). The upshot is that when a service instance runs from a 10GE port to a 1GE port then the client side will have to be deal with dot1Q VLAN tags.
* Interesting to note that we already have the capability to “break” the “dot1Q VLAN tag having E2E significance” paradigm!
Features:
uses GFP/VCAT
10GE port (supporting multiple instances)
use 802.1Q VLAN tags as IDs
sub (or >) 1G possible

8. Services over GÉANT2 Point-to-point GE (10G SDH access) GÉANT2
Connect. Communicate. Collaborate
Services over GÉANT2
Point-to-point GE (10G SDH access)
POP C
POP A
VCG X
VCG Y
GÉANT2
POP D
POP B
Obviously this flies or dies based on whether or not different vendor implementations of GFP are interoperable. We have done some previous testing between 1GE ports (Alcatel<->Nortel) and this has worked fine but we have not yet done this with 10GE ports. Some “service trials” being set up at the moment will essentially put this to the test (for both Alcatel<->Nortel and Alcatel<->Ciena)
Features:
uses GFP/VCAT
10G SDH port
GFP done in NREN
sub 1G possible

9. Services over GÉANT2 Managed wavelength service GÉANT2
Connect. Communicate. Collaborate
Services over GÉANT2
Managed wavelength service
POP C
POP A
GÉANT2
POP D
POP B
Note that this avoids the MCC (switch) altogether and clients connect straight to transponders on the WDM system (the picture is trying to show this but it is not that clear).
Features:
10G only
SONET/SDH or 10GE LAN PHY
static
10GE is “full-rate”

10. LCG TIER0 – TIER1 Optical Private Network - OPN,
RAL
Nordugrid
FNAL
BNL
TRIUMF
ASCC UK DK
CERN T0 CH NL
SARA
GEANT2 DE FR IT ES
GRIDKa
IN2P3
PIC
CNAF

11. Agenda GEANT2 status and developments
End to end services and the hybrid infrastructure
JRA3 introduction
Monitoring

12. The JRA3 Activity of GN2
JRA3 is investigating the provision of ‘Bandwidth on Demand’ services to the NREN community
The goal implies an environment that is:
Multi-domain
Using multiple transmission technologies
SDH, GFP over SDH, L2 MPLS VPN, Ethernet
Requirements for:
end-to-end delivery of a non-contended capacity
a standardized interface for service requests at end-points
service level indication to end-users
advance reservation (scheduled)
modular and technology independent implementation

13. JRA3 architecture Key elements: - Inter-Domain manager (IDM)
- Domain manager (DM)
Resource modeling (aka Abstract representation)
Path finder
Technology proxies
Standardized interfaces
L2 MPLS VPN
Each domain participating in the BoD service provisioning needs to operate an IDM and honor the IDM-DM and IDM-IDM interfaces.
The local DM can be any technology, just a proxy is needed towards the IDM

14. JRA3 Distributed approach
(1)
(6)
(8)
(4)
(10)
(9)
(5)
(7)
(3)
Inter-domain path-finding
(2)

15. JRA3: Current status Framework and Architecture defined
IDM functional specification released
IDM phase 0 (simplified in some modules) implementation and testing done
Draft abstract notation available
Working on Pathfinding module , IDM phase 1 and abstract representation

16. Agenda GEANT2 status and developments
End to end services and the hybrid infrastructure
JRA3 introduction
Monitoring

17. Problem space E2ELink A-B Domain B Point A Domain A Domain C PointB
An E2Elink from point A to point B in real (NREN) world traverses a number of different administrative/monitoring/technology domains.
Collectively GN2 community (and beyond) now seeks real-time monitoring of entire link (A<->B) and some degree of breakdown of this into constituent (“DomainLink” and inter-domain) parts. The latter will be used by the centralised E2ECU (E2E coordination unit) to help them with their task of monitoring such services and providing a first port of call to users of such services – all part of the efforts to make the NRENs+DANTE appear to E2ELink users more like a single coherent service provider.
Monitoring info constrained in the first instance to simple up/down status (out of practicality). Placeholders exist for more info like being able to declare a “degraded” status in addition to just up or down and to provide PM (performance monitoring) data but work needs to be undertaken to further define this (planned in GN2 year-3).
Note also that this work is pretty much focussed on E2E lambda services (rather than more generic P2P services) so the existence of WDM systems is more or less assumed. However, the principles should mostly be applicable to other P2P services such as EPL carried over multiple technology domains.
Goal: (near) real-time monitoring (link status) of constituent DomainLinks
(and links between domains) and whole end-to-end Link A-B.

18. Approach E2ELink A-B Domain B Point A Domain A Domain C PointB
perfSONAR
MP or MA
perfSONAR
MP or MA
PointB
perfSONAR
Measurement Point (MP)
or Measurement Archive (MA)
DomainLink and
(partial) ID_Link info
perfSONAR compliant MPs or MAs fed with DomainLink and (partial) ID_Link info from domain-specific NMS or homegrown correlating alarm/trap monitoring system IN REAL-TIME.
E2Emon correlator application periodically polls distributed MP/MAs (using regular perfSONAR-like web services approach) and feeds correlated info to whatever requires it e.g. a “weathermap” for use by end users of E2ELinks and E2ECU operators’ umbrella monitoring systems (e.g. Nagios)
Note: MA (measurement archive) provides some future-proofing in so much as historical up/down info is maintained (in distributed manner). E2Emon correlator can, of course, store historical data (centrally) as well (especially if domain only has MP available)
E2ECU
operators
“Weathermap”
view for users
E2Emon
correlator

19. Demo

20. Thank you

21. JRA3 Why an Inter-Domain Manager
The effort to provision end-to-end Bandwidth on Demand services in the European scenario requires specific developments in inter-domain collaboration
Splitting intra-domain management functionalities from inter-domain ones in separate modules, allows multi-domain R&D to proceed autonomously and focus on this less standardized area
At the same time, it allows to leverage existing inter-domain managers through wrappers/proxies and interfaces, exploiting a modular approach
This effort can provide solid experience for brokering services other than Bandwidth on Demand

22. JRA3 Domain independence
Collaborative and distributed effort through newly defined interfaces which extend the NNI standards
No centralised management
Better resilience
A common naming and addressing schema for a large amount of devices
An abstract network representation to ensure faithful service description
Possibility to hide domain internals
Clear separation of control and data plane also at the physical level when needed

23. JRA3: IDM multi-domain issues
The IDM faces a number of requirements and corresponding challenges related to its multi-domain scope:
domain independence for resource usage policies and technological choices
a service and network abstraction schema (language/notation) to describe very different networks, with different policies
a schema to allow a clear specification of the service
a network abstraction which allows inter-domain information exchange independently of the underlying technologies
stitching of multi technology domains
multi-domain path finding procedure
advance reservation
monitoring
Authentication and Authorization