72nd ietf dublin july 2008 framework and requirements for virtual private multicast service (vpms)...

10
72nd IETF Dublin July 2008 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)

Upload: thomasine-henry

Post on 29-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

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)

Page 2: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

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 draft’s objective– Introduce service framework and become a base reference– Specify functional requirements to guide a proper solution

Page 3: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

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)

Page 4: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

Reference Model

• A “VPMS instance” corresponds to a unique unidirectional P2MP topology

• AC is configured as "sender" or "receiver" not both.

CE: Customer EdgePE: Provider EdgeAC: Attachment Circuit

RoutedBackbone

CE1

CE4

CE2

CE3

CE5 CE6

AC1

AC4

AC2

AC3

AC5 AC6

Sender

Sender

Receiver

Receiver

Receiver Receiver

VPMS AVPMS A

VPMS A

VPMS B VPMS B

VPMS B

VPMS BVPMS A

PE3

PE1 PE2

Page 5: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

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.

Page 6: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

Multiple Source Support

VPMSPE1VPMSPE1

VPMSPE2VPMSPE2

CE1 CE2

CE5

AC1 AC2

AC3 AC4

CE4

VPMSPE3

VPMSPE4

• 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)

VPMS AVPMS A

VPMS A VPMS A

Sender

Receiver

Sender

Receiver

Page 7: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

Reverse Traffic Support

• 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 )

CE2

CE1

CE3

CE5

AC1

PE2

AC2

AC5

ReceiverVPMS A

VPMS A

PE4

PE1

TxRxAC6

PE3

VPMS BAC3 AC4

Tx Rx

Rx Rx

SenderVPMS AVPMS B Receiver

ReceiverVPMS A

SenderVPMS AVPMS B

Receiver

Unique instance per direction

Page 8: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

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)

Page 9: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

Activation / Deactivation

• 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)

CE2

CE1

CE3

CE5

AC1

PE2

AC5

Receiver(activated

)

VPMS A

PE4

PE1

PE3

AC2 AC3

SenderVPMS A

NO VPMS provisioned

VPMS A

Single-sided activation on each AC at source PE

CE4

AC4

Receiver(deactivated and not receiving data)

VPMS AReceiver(activated

)

deactivated

Page 10: 72nd IETF Dublin July 2008 Framework and Requirements for Virtual Private Multicast Service (VPMS) draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt Yuji

72nd IETF Dublin July 2008

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