Issues in Provisioning Internet-wide VPN Services

1
Issues in Provisioning Internet-wide VPN Services

• Christian JACQUENET
• christian.jacquenet_at_francetelecom.com

2
Agenda

• Context and motivation
• Issues and requirements
• Next steps

3
Context and Motivation

• Emerging triple-play services
• Some of the applications are QoS-demanding
• TV broadcasting, VoIP
• Some others require traffic isolation
• Videoconferencing, corporate-centric traffic,
  signaling traffic
• Most combine such requirements
• Such services are deployed at the scale of the
  Internet
• Hence raising issues in provisioning
  (inter-domain) VPN resources with the required
  level of quality

4
Towards Automation?

• From service subscription to deployment
• Hopefully reducing the cost of operation
• Dynamic provisioning of network resources
• Yielding interconnection design issues, e.g.
• Identification of the participating devices
• Establishment and activation of VRF instances,
  MP-(e)BGP peering relationships
• Dynamic enforcement of a set of VPN-specific
  policies
• (Uni- and multi-cast) Routing, forwarding,
  traffic engineering, QoS and security policies

5
Contractual Commitments

• Provisioning of QoS-based VPN services implies
  contractual agreements
• Between participating service providers
• Based upon a common understanding of what QoS
  means
• Hopefully yielding standardized SLS templates
• SLS contents to be negotiated between service
  providers
• Need for exchanging QoS information between
  domains
• To address customers' requirements accordingly

6
Elaborating on QoS Requirements

• Concepts of SLA/SLS/TCS have been promoted
  through the DiffServ effort
• But contents are left to service providers
• Hence raising issues when attempting to use SLS
  specifications as a contractual means to enforce
  VPN-related QoS policies in an inter-domain
  environment
• Service providers need to agree on (a set of)
  well-defined QoS parameters
• Not to mention the associated yet necessarily
  consistent metrology
• QoS policies may dramatically differ from one
  domain to another

7
Elaborating on Security

• Need for a trust model
• To securely deliver the VPN service
• To secure VPN route announcements between domains
• Check also the sidr BoF session
• To provide access to the VPN facility to the
  entitled users
• Wherever they may be (even in motion)

8
Proposed Approach

• Post a requirements draft
• Detail issues in provisioning QoS-based
  inter-domain VPN services
• As a complementary document to RFC 4031
• Document is being circulated on the mavs
  ("Multi-AS VPN Services", mavs_at_ietf.org) mailing
  list
• Check also www.ipsphereforum.org
• Solicit IETF to host a BoF session on this topic
• Hopefully to be held in Dallas (03/06)
• To further discuss issues and whether they should
  be addressed by the IETF or not