1 / 10

Packet Pseudowire Encapsulation over an MPLS PSN draft-bryant-pwe3-packet-pw-02.txt

Packet Pseudowire Encapsulation over an MPLS PSN draft-bryant-pwe3-packet-pw-02.txt. {Stewart Bryant, Sami Boutros, Luca Martini, Siva Sivabalan, George Swallow, David Ward} @ Cisco Systems Andy Malis @ Verizon Communications. Candidate Mechanisms.

najwa
Download Presentation

Packet Pseudowire Encapsulation over an MPLS PSN draft-bryant-pwe3-packet-pw-02.txt

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. Packet Pseudowire Encapsulation over an MPLS PSNdraft-bryant-pwe3-packet-pw-02.txt {Stewart Bryant, Sami Boutros, Luca Martini, Siva Sivabalan, George Swallow, David Ward} @ Cisco Systems Andy Malis @ Verizon Communications

  2. Candidate Mechanisms During the Pkt-PW design investigation we considered four candidate mechanisms: • A protocol identifier (PID) in the PW Control Word (CW) • A PID label • Parallel PWs - one per protocol • Virtual Ethernet

  3. PID In CW • Proposed in draft 0 of this document • PID appended to the generic CW • CW effectively 6 bytes or 2 bytes • Virtual PPP interface • Not as simple as the PID label or multiple PW approaches • Not deployable on many existing h/w platforms

  4. PID Label • Described in Version 2 of this doc. • PID label is extra label after PW label. • New LDP FEC signaled protocol type to PID label binding.

  5. PID Label 2 • Complies with strict defn. of MPLS, but not with how some h/w designer's interpreted MPLS • Assumption in many designs that forwarding decision made on the basis of a single label • Not supported by commodity chips sets • New h/w would inc. cost of deployment and delay the introduction of packet PW service.

  6. Parallel PWs • One PW per protocol type • A packet-PW consists of a bundle of PWs • Simple and efficient from a forwarding point of view • # of parallel PWs normally relatively small - IPv4, IPv6, MPLS and CLNS

  7. Problems with Parallel PW • Lack of fate sharing protocol types can lead to complex faults difficult to diagnose • Either • Run an OAM on each PW and bind results, or • Single OAM session on one PWs as a proxy for the others - mitigated through the use of BFD. • The need to configure manage and synchronize the behavior of a group of PWs as if they were a single PW

  8. Virtual Ethernet • Use virtual Ethernet and Ethernet PW [RFC4448] to carry the user traffic • Simple and can be implemented today without any further standards action • Some deployed equipments can already do this • Larger MTU than the other approaches, but – not an issue on jumbo-gram n/w

  9. Analysis • Parallel PW rejected because of operational complexity and the breaking of fate sharing • The PIDL may break implicit behavioral and label stack size assumptions – may need new h/w • The PID in CW new h/w • Virtual Ethernet – • Well known protocol stack • Well known (internal) client interface. • Widely implemented

  10. Recommendation Having considered a number of initially promising alternatives simplicity and existing hardware make the virtual Ethernet packet PW the most attractive solution Draft includes a number of applicability considerations

More Related