Framework and Requirements for Virtual Private Multicast Service VPMS draftkamitel2vpnvpmsfrmwkrequi

1
Framework and Requirements for Virtual Private
Multicast Service (VPMS)draft-kamite-l2vpn-vpms-
frmwk-requirements-01.txt

• Yuji Kamite (NTT Communications)
• Frederic Jounay (France Telecom)Ben
  Niven-Jenkins (BT)

2
Introduction

• What is VPMS?
• VPMS is defined as a Layer 2 service that
  provides point-to-multipoint connectivity for a
  variety of Layer 2 link layers across an IP or
  MPLS-enabled PSN.
• Difference from other L2VPNs
• VPWS supports point-to-point only no replication
• VPLS supports replication but requires full-mesh
  and MAC forwarding (VSI)
• WG Re-chartering
• L2VPN WG Re-chartering proposal to take VPMS
• PWE3 WG Re-chartered to take P2MP-PW (potential
  solution)
• This drafts objective
• Introduce service framework and become a base
  reference
• Specify functional requirements to guide a proper
  solution

3
Use Cases

• Ethernet Use Case (Section 4.1)
• IP-based TV broadcasting
• Audio/video device with Ether interface (MPEG-TS,
  HD-SDI)
• MPEG-TS/IP/Ethernet in DVB-H with static
  multicast
• ATM-based Use Case (Section 4.2)
• IP multicast wholesale
• p2mp PVPs/PVCs
• TDM-base Use Case (Section 4.3)
• Mobile backhauling -- deliver the clock
  (CESoPSN, SAToP, TDMoIP)

4
Reference Model
VPMS A
VPMS A
PE1
PE2
CE1
CE2
Sender
Receiver
AC2
AC1
VPMS B
VPMS B
CE4
CE3
VPMS B
Receiver
AC3
Sender
AC4
VPMS A
Routed Backbone
PE3
AC6
AC5
CE Customer Edge PE Provider Edge AC
Attachment Circuit
CE5
CE6
VPMS A
VPMS B
Receiver
Receiver

• A VPMS instance corresponds to a unique
  unidirectional P2MP topology
• AC is configured as "sender" or "receiver" not
  both.

5
Requirements Summary

• Customer Requirements (Section.2)
• Service Topology
• Transparency
• QoS
• Protection and Restoration etc.
• Provider Requirements (Section.3 )
• Scalability
• PW signaling / PSN tunneling (Details will be
  covered by P2MP-PW Reqts work)
• Auto-Discovery
• Activation and Deactivation
• Inter-AS etc.

6
Multiple Source Support
AC2
CE1
CE2
AC1
VPMS A
VPMS A
Sender
Sender
VPMSPE1
VPMSPE2
VPMSPE3
VPMSPE4
AC3
AC4
VPMS A
VPMS A
CE5
CE4
Receiver
Receiver

• MUST support multiple sender topologies in one
  VPMS instance
• Each P2MP topology MUST only have a single
  sender, however multiple P2MP topologies can be
  grouped together into a single VPMS instance.
• (For protection and restoration at sender-side)

7
Reverse Traffic Support
CE1
Sender
VPMS A
Tx
Rx
VPMS B
Receiver
AC1
AC2
PE1
VPMS B
AC4
AC3
VPMS A
VPMS A
CE2
CE3
Receiver
Receiver
Rx
Rx
VPMS A
PE2
PE3
PE4
Unique instance per direction
AC6
AC5
Tx
Rx
Receiver
VPMS A
CE5
Sender
VPMS B

• Every AC is considered unidirectional
• Direction is an additional element to identify a
  unique AC
• L2 header/circuit (e.g., VLAN id, Physical port
  )plus traffic direction (Tx or Rx )

8
Auto-discovery

• Discovering VPMS Related Information
• SHOULD support auto-discovery methods to minimize
  the amount of configuration the SP must perform
• Information Example
• PE router ID / IP address as location
  information
• Information to identify ACs and their VPMS
  instance
• CE role in each VPMS (Sender and/or Receiver)

9
Activation / Deactivation
VPMS A
CE1
Sender
Single-sided activation on each AC at source PE
AC1
PE1
AC3
AC2
VPMS A
CE2
CE3
Receiver(activated)
NO VPMS provisioned
PE2
PE3
PE4
AC4
AC5
deactivated
VPMS A
VPMS A
CE5
CE4
Receiver(activated)
Receiver(deactivated and not receiving data)

• SHOULD provide a way to activate/deactivate the
  administrative status of each CE/AC.
• SHOULD allow single-sided activation operation at
  a sender PE (for centralized control)

10
Next Step

• Remaining major work
• OAM
• Security
• This draft is being well coordinated with P2MP
  Reqts work (draft-jounay-pwe3-p2mp-pw-requirements
  ) that is proposed in PWE3
• Propose to adopt this as a WG document- to have
  consensus on this basic framework