Scenarios for L1VPNs September 26, 2005 Discussion paper for NOBEL Paris Meeting September 2005

1. Scenarios for L1VPNs September 26, 2005Discussion paper for NOBEL Paris Meeting September 2005 Georg Lehr, T-Systems SSC ENPS PCT 52gl

2. Outline • L1VPN – A simple approach, benefits for customers and providers • Scenarios for Takeda framework • Assessment of L1 VPN • Discussion of broadcaster’s scenario

3. Simple view … on L1VPNs • Definition of Virtual Private network: • Network can be operated as if it was fully owned by the customer. • e.g. private address plan • full management visibility and management capabilities on own resources • no impact of “outer world” (security/privacy; closed user group …) • This ownership is only virtual, as it is partly shared with other customers • Sharing can be on: • data plane level : (transmission resources such as subnetworks, nodes, or links are shared) • level of control : • control plane hard and software; • but: information exchanged by routing protocols is dedicated (membership, customer routing info and provider routing info is only exchanged between the PE and CE members of the VPN). • level of management and operation: • management infrastructure is shared, • operational labour and expertise is shared. • but: management information is dedicated (customer’s management view and capabilities are restricted to VPN resources)

4. Simple view … on L1VPNs • Sharing has two aspects: • economies of scale regarding resources and operation. • economies of expertise • These aspects enable • Attractive costs for production • Outsourcing and other value added services • Additional effort for implementation • limitation of distribution of information within VPN • in CP via routing protocols • in MP via access rights on resources • both: measures to guarantee security • limitation of access to resources • in CP policing functions (CAC-functions) • in MP see above • both: measures to guarantee security • Competition, if services are comparable and provided via standardized interfaces • data level is standardized • CP is going to be standardized • MP interfaces: chance to provide proprietary solution with high customer benefit (e.g. in systems solution business).

5. Customer benefits … of L1VPNs • Customer can outsource operation of an Layer 1 Network. This takes the burden from the customer: • to perform the network management tasks • to provide a 7/24 service / helpdesk • to train and employ people with a very specialized operational experience (with skills often far away from the core business). • to operate a complicated network management infrastructure • Sharing of resources: • customer can afford small network by sharing the full cost of ownership with other customers. The smaller the network is, the better the economy of scale (for equipment and labour).

6. Customer benefits (ctd.) … of L1VPNs • Customer does not have to care about technical details, but can rather rely on parameters guaranteed in SLAs; the provider has to take care how availability goals can be met - also for different routes: • availability • latency • SNR for optical networks • reachability for dynamic services • Customer can integrate networks from different providers with an optimized cost / quality relationship. • different layers • different regions • “in parallel” (to implement diversity) • in sequence (to build a global network, if no global provider is available or is too expensive)

7. Provider benefits … of L1VPNs • Provider can sell a value added service to the customer, not only connectivity but rather: • supervised connectivity • with guaranteed availability • guaranteed reachability (in terms of busy hour call attempts) • guaranteed latency • Management capabilities such as • Detailed management access from simple web applications (visibility, fault, performance …) • Advanced billing functions (e.g. interfaces to SAP …) • Other integration functions (e.g. integration with customer’s order management, SAP …) • Helpdesk and 7/24 h support • Provider can make better use of spare resources • Provider can share the effort for expensive lower layer network management integration; customer needs only a simple browser.

8. ITU-T  Takeda draft • The ITU-T provided in the Y series some generic views on L1VPNs. • This work has been used as starting point for discussion in IETF. • draft-takeda-l1vpn-framework-04.txt: Tomonori Takeda (Editor): “Framework and Requirements for Layer 1 Virtual Private Networks”; June 2005

9. Service requirements and service models Possible combinations of info exchange and sharing draft-takeda-l1vpn-framework-04.txt

10. Service requirements and service models Significance of the table • The table provides a mapping between service models • overlay • overlay extension, • virtual node, • virtual link, • per VPN peer to functionality provided by the network • signaling plus • different levels of information transfer • The table distinguishes further between shared and dedicated dataplanes.

11. Service models are classified by semantics of information exchanged over the customer interface Taxonomy of L1VPN Service Models Type of the customer interface Management based service model Control based service model Type of information exchanged Signaling based service model (Overlay service model)* Signaling and routing service model UNI (Overlay) type of interface NNI (Peer) type of interface Type of membership information exchanged Type of routing information exchanged Overlay Overlay (extension) Virtual link service model Per VPN peer service model Virtual node service model * [GVPN] calls this service GVPW (generalized virtual private wire service) Draft-takeda-l1vpn-framework-03.txt

12. Information exchange at the PE-CE Interface Can be used to classify the scenarios • Signaling • Membership information : • {(CPIn ,PPIn,); ….}; (CPI are private, PPI public addresses) • local (same PE) and remote (other PEs) • distribution restricted to the specific VPN • Customer network routing information • Provider network routing information GMPLS enabled BB CE PE PE CE CPI PPI link PPI link CPI Customer Network Provider Network Customer Network

13. Shared data plane vs. dedicated data plane Can be used to classify the scenarios • Sharing the data plane enables the network operator to better utilize the resources. He can share this advantage with the customer. • Sharing of the resources has impact on: • resource availability • security • Sharing of resources implies, that the customer has no influence on the routing process (hence in a a shared data plane, no provider routing info is exchanged, see table. Therefore, sharing has also impact on: • latency • availability of the connection, (as the MTBF depends on the length of the connection): • performance (in the case of transparent optical L1VPNs) • On the other hand, availability of resources can be guaranteed only on the level of probabilities. This probability is agreed upon in the SLA (e.g. as BHCA = busy hour call attempts). Penalties are fixed for the case when the statistical value can not be met by the operator in an agreed time interval. • The network operator must try to meet the SLA by providing a reasonable basis of resources. The planning process must take into account a predicted user behaviour, the cost for resources and penalties.

14. UNI Customer 2 is connected to UNI can connect to has visibility Customer 1 Customer 2 Scenario: Overlay Model UNI-C based VPN UNI Customer 1

15. Scenario: Overlay Model VPN as a Closed User Group (CUG) • Restriction of Management Visibility: • management view only on resources that have been ordered /are under service contract • Restriction of reachability: • only nodes within the user group (VPN-internal) can call each other • only calls from nodes within the user group (VPN-internal) are accepted or: • outgoing access to VPN-external destinations • incoming access from VPN-external sources • Generally • One contract, one Service Level Specification, one bill,... • Management requirements / CP requirement • needs to be configured • needs to be policed (whitelist …) • Implementation issue: where is this done in the CP? CAC? • Add new member • Change address of member? • Configure policy

16. UNI Customer 2 Scenario: Overlay Model VPN as a (CUG) UNI Customer 1 SLA NMI („X“) NMS Network Operator CNM Customer 1 UNI Domain Customer 1 Domain Customer 2 Network Operator Domain

17. Scenario: Overlay Model Assessment • Implementation effort comparatively low • UNI required • PE must implement mapping of private (CPI) addresses, if these are used in the • Implementation and configuration of policing functions within provider network • Membership information needs to be distributed offline and configured manually in the CEs. • Acceptable, if customer network is static (e.g. customer network may mainly consist of L2 and L3 devices. This may be the normal case) • Resilience features can be used as far as they are supported by the UNI (UNI2.0) • Dynamic services.

18. Scenario: Overlay Extension Model Assessment • Implementation effort higher compared to Overlay Model • UNI required • PE must implement mapping of private (CPI) addresses, if these are used in the • Implementation and configuration of policing functions within provider network Plus: • BGP • BGP VPN Discovery • attractive only, if network structure is highly dynamic } additional effort

19. Scenario: Virtual node Description NW: GMPLS enabled BB CE CD CE CD CD CD CD CD CD CE CE CD CD CD “Virtual Node” Views on the NW: CD CD CD CD CD CD CD CD CD CD One Routing Domain

20. General Scenario: Two Providers in parallel Description Provider1 NW: CD CD CE CE CD CD CD CD CD CE CE CD CD CD Provider2 • Scenario supported by any L1 transmission scheme. • leased line • dynamic leased line • overlay / extended overlay • virtual node, virtual link • per VPN Peer

21. Scenario: Virtual node Assessment • Implementation effort higher • UNI required • PE must implement mapping of private (CPI) addresses, if these are used in the • Implementation and configuration of policing functions within provider network • BGP • BGP VPN Discovery Plus • Protocols providing transport of customer routing information • attractive only, if • real time dynamic services are required • network structure is highly dynamic and • CP routing is used in the L1VPN domain as a whole (see previous slides) • attractive for carriers carrier • not needed by broadcasters } additional effort

22. Scenario: Virtual link Description CE PE NW: PE PD PD PD PD PD Routing info exchange on: • CE-PE links • remote customer sites • virtual links • TE link attributes (abstraction of the provider NWdetermined from data link properties) PD PD PD PD PE PD PD PD PD PD PD PD PD PD PD PE PE PD PD PD • TE Link attributes e.g.: • latency • performance • shared risks PE PE CE data link resourcesexclusively allocated to virtual link/VPN PE virtual link topology distributed via routing protocols PE PE

23. Scenario: Virtual link Assessment • Dedicated resources • scheduling can be performed internally, resources always guaranteed by provider • effect of resource sharing smaller than in overlay and virtual node. • Properties of links known and distributed via routing protocols • Customer has all knowledge to configure properties of e2e-connections • availability • performance • latency … • SLA on basis of links? • Less sharing of operation and management infrastructure • Integration of provider network via CP protocols possible. • Attractive for broadcasters for scheduled applications, where100% call success is required. • Attractive for guaranteed availability, latency for SANs, performance for live events (jitter)

24. Scenario: Per VPN Peer Description CE PE NW: PE PD PD PD PD PD Routing info exchange on: • CE-PE links • remote customer sites • partition portion of provider NW: • virtual links with TE attributes • virtual nodes virtual node PD PD PD PD PE PD PD PD PD PD PD PD PD PD PD PE PE PD PD PD • TE Link attributes e.g.: • latency • performance • shared risks PE PE CE data link resourcesexclusively allocated to virtual link/VPN PD PE virtual link topology distributed via routing protocols PE PE

25. Scenario: Per VPN Peer Assessment • Dedicated resources • scheduling can be performed internally, resources always guaranteed by provider • effect of resource sharing smaller than in overlay and virtual node. • Properties of links known and distributed via routing protocols • Customer has all knowledge to configure properties of e2e-connections • availability • performance • latency … • SLA on basis of links? • Less sharing of operation and management infrastructure • Integration of provider network via CP protocols possible. • Effort higher without added value, may be reasonable only for large networks or critical parameters.

26. Scenario: Management based model Assessment If there is no explicit need for near real-time provisioning of connections, management based service models are the better choice: • easier to implement setup functionality (is a subset of management functionality of the provider) • easier to implement mapping of private names to public names (can be done in one database) • easier to implement policing (only one interface has to be policed and compared with the SLA) • easier to implement security (only one interface has to be supervised, standard technology) • easier to provide value added management functionality such as advanced management functionality (see benefits). • easier to offer outsourcing (as the customer view is a subset of the operator’s view).

27. Summary Shared data plane vs. dedicated data plane • VPN features are: • virtualization of resources • virtualization of operation -> outsourcing • Virtualization of resources: • high technical effort by CP • trade-off between resource spending and penalties difficult due to unknown user behaviour • only acceptable for customers, if no special requirements regarding latency , security, .. • Virtualization of operation is attractive for customers • Sharing of management system infrastructure • sharing of operational support • less attractive the higher the functionality provided by the network is … • … can be achieved by management as well …. make it simple !!! start with management

28. Requirements for Broadcasters Management and Topology • Management • Detailed billing, potentially allocation to specific, broadcaster internal projects • Integration with electronic order management. • Fluctuation of nodes without new SLA negotiations with operator low • Topology: • Integration of quasistatic star-shaped network connecting the local studios with the headquarters of the “Landessender” • Transfer to satellite uplinks and DVB-T transmitters. • Dynamic for broadcast production house • Potentially in future: • Video on demand • SAN-like applications for internal production purposes (archive for movies).

29. Requirements for Broadcasters (ctd.) Requirements • Requirements for these applications • Resilience • Latency • Performance (BER, ES, …) • Performance (SNR …) for transparent networks • Scheduling • 100% call establishment success (for live events) • call establishment success < 100% (for production; file based) • LAN-WAN-connection • Presumably, broadcasters do not have the requirement to interconnect several medium or large L1 networks

30. Requirements for Broadcasters (ctd.) Business model and scenarios • Business Model • Broadcasters buy: • own equipment • lease fibers on long term from different providers • outsource operation to small providers; CPEs from this operator • Alternative solutions based on VPNs must provide benefits for broadcasters concerning • cost structure • flexibility • performance • ease of interfacing to existing production control systems on the broadcasters' side • Scenarios • CUG: incoming calls from post production studios • Outgoing calls to post production studios and co-operating broadcasters  Make it easy - listen to the broadcasters' needs and try to accommodate utilizing a re-usable solution } should be easy to handle