1 / 8

Issues in Provisioning Internet-wide VPN Services

Issues in Provisioning Internet-wide VPN Services. Christian JACQUENET christian.jacquenet@francetelecom.com. Agenda. Context and motivation Issues and requirements Next steps. Context and Motivation. Emerging triple-play services Some of the applications are QoS-demanding

raisie
Download Presentation

Issues in Provisioning Internet-wide VPN Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Issues in Provisioning Internet-wide VPN Services Christian JACQUENET christian.jacquenet@francetelecom.com IETF 64 Ops Area Meeting – 07/11/05

  2. Agenda • Context and motivation • Issues and requirements • Next steps IETF 64 Ops Area Meeting – 07/11/05

  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 IETF 64 Ops Area Meeting – 07/11/05

  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 IETF 64 Ops Area Meeting – 07/11/05

  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 IETF 64 Ops Area Meeting – 07/11/05

  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 IETF 64 Ops Area Meeting – 07/11/05

  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) IETF 64 Ops Area Meeting – 07/11/05

  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@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 IETF 64 Ops Area Meeting – 07/11/05

More Related