PWE VPLS Yaakov J Stein June 2006 Chief

PWE + VPLS Yaakov (J) Stein June 2006 Chief Scientist RAD Data Communications

Contents n Interworking n VPNs n PWs n TDM PWs n Ethernet PWs n Other PWs n PWE control protocol n L 2 VPNs n LDP vs. BGP n Provisioning VPLS n Generalizations n L 3 VPNs 2

Interworking 3

Tunneling - interworking mating different network protocols is called interworking protocol converter goes by various names : – interworking function (IWF) – gateway (GW) simplest case is network interworking easily provided by tunneling native network infrastructure network native network 4

Tunneling - provider networks users traditionally have private networks they interconnect their sites using leased lines – no contention with outside users – guaranteed privacy – complex and costly maintenance customer network leased line customer network service providers (SPs) can provide virtual private networks provided by (once again by) tunneling edge-to-edge 5

Basic emulation by tunneling customer network physical link customer network end to end edge to edge provider network customer network emulated link provider network edge 6

Interworking motivation there are many different types of network traffic (voice, video, file-xfer, etc) all types fall into one of three classes: – Real-time constant bit-rate – Real-time variable bit-rate – Non-real-time (packet) there are many different types of network (IP, ATM, FR, Eth, etc) most were originally designed for a specific type of traffic providers with one type of network infrastructure want to fully exploit it they desire to carry all types of network traffic 7

Service Interworking Service interworking: direct conversion between 2 native service formats Native Service A service interworking function Native Service B 8

VPNs 9

Conventional Ethernet-IP model Ethernet IP Ethernet conventional model: n Ethernet is a LAN technology – last 100 m – 10 s of hosts n IP is a WAN technology – data transported in native IP – different L 2 technologies for last segment modern Ethernet wants to be more 10

Virtual Private Networks service provider network SPs want to offer customers site interconnect service since the private networks are interconnected over a public PSN this results in a Virtual Private Network unlike the traditional WAN architecture the entire native packet/frame must be tunneled Example: Transparent LAN Service (TLS) 11

Basic (L 2, L 3)VPN model physical link customer network emulated link customer network Customer Edge (CE) Provider provider Edge network (PE) AC = Attachment Circuit Customer Edge (CE) AC = Attachment Circuit provider network may be L 3 (e. g. IP) or L 2 (e. g. Ethernet) 12 customer network

(L 2, L 3)VPN in more detail C C CE CE C C customer 1 network P P P C C customer 2 network P provider network CE C CE P PE customer 2 network PE PE C P CE C C C Key Customer router/switch customer 1 network Customer Edge router/switch Provider Edge router/switch 13

L 3 encapsulation for simplicity, let’s think of an IP network : the traditional architecture uses the following packet formats: WAN Eth hdr IP hdr payload Eth FCS WAN L 2 hdr IP hdr payload a VPN model (Ether-IP) uses the following packet formats: WAN Eth hdr IP hdr payload Eth FCS WAN L 2 hdr IP hdr Eth hdr IP hdr payload Eth FCS* 14

VPN Challenges 192. 115. 243. 79 192. 115. 243. 19 SP network 192. 115. 243. 19 Security Private IP addresses Multiple higher-layer protocols SP resource requirements Complex provider - customer relationship 15

MPLS solves IP address problem 192. 115. 243. 19 2 1 MPLS network 1 192. 115. 243. 19 MPLS label IP header payload assume customers 1 and 2 use overlapping IP addresses then C-routers have inconsistent tables ingress PE-router pushes a label P-routers see only MPLS label P-routers don’t see IP addresses - no ambiguity P-routers see only the MPLS label - not LAN IP addresses PE routers know how to map CE LANs 16

VPN types n Legacy – proprietary leased-line (not virtual) – Frame Relay over E 1/T 1 – ATM over E 1 or multiple-E 1 n Pure IP – IPSec tunnel – L 2 TP tunnel n MPLS L 3 VPN – RFC 4364 (ex 2547 bis) n MPLS L 2 VPN – VPWS / VPLS 17

Pseudowires Pseudowire (PW): A mechanism that emulates the essential attributes of a native service while transporting over a packet switched network (PSN) 18

Pseudowires Packet Switched Network (PSN) – network that forwards packets – IPv 4, IPv 6, MPLS, Ethernet (although IETF does not touch) a pseudowire (PW) is a mechanism to tunnel through a PSN PWs are bidirectional (unlike MPLS LSPs) PW architecture is an extension of VPN architecture 19

Pseudowire Emulation Edge to Edge Customer Edge provider’s PSN (CE) Customer Edge Provider Edge (CE) (PE) Customer Edge native service Pseudo. Wires (PWs) native service (CE) 20

Provider Network Architecture provider network is composed of: • Provider routers (P routers) • Provider edge routers (PE routers) P router native service PE router P router A tunnel may contain many PWs PE router P router 21 native service

IETF PWE 3 WG In the Internet Area of the Internet Engineering Task Force Native (layer 1, 2) services : n ATM (port mode, cell mode, AAL 5 -specific modes) n FR n Ethernet (DIX, 802. 3, VLAN) n TDM (SONET/SDH, E 1, T 1, E 3, T 3) n … Supported Packet Switched Networks (PSNs) n IPv 4 n IPv 6 n MPLS n L 2 TPv 3 n (not Ethernet …) 22

PWE 3 WG Charter n Edge-to-edge emulation and maintenance of PWs – tunnel creation and placement out of scope n Network interworking, not service interworking n Must not exert controls on underlying PSN – but diffserv, RSVP-TE can be used n Use RTP when necessary – for real-time functions, clock recovery n Realize that emulation will not be perfect – need applicability statement for each native service n WG will produce the following documents – requirements (RFC 3916), architecture (RFC 3985) documents – control protocol definition – service specific encapsulation documents for each native service 23

MPLS Much of the PWE work is focused on MPLS n Emulated services have Qo. S and TE requirements – – n IP is basically a “best effort” service diffserv and RSVP extensions not prevalent MPLS can provide TE guarantees RSVP-TE (CR-LDP) allows TE signaling IP provides no standard “bundle” multiplexing method – – – Dictionary: UDP/TCP ports provide application multiplexing RTP uses ports in a nonstandard way L 2 TP includes a multiplexing mechanism MPLS label stack provides natural multiplexing method Using “inner labels” provides two layers of switching (like ATM VP/VC) MPLS-f inner label outer label(s) ITU-T interworking label transport label(s) IETF PW label tunnel label(s) 24

Simple MPLS solution CE CE CE ACs PE P CE P PE ACs CE CE each customer network mapped to pair of (unidirectional) LSPs supports various AC technologies each native packet/frame encapsulated with MPLS label scaling problem: n requires large number of LSPs n P-routers need to be aware of customer networks 25

(Martini) Pseudowires CE transport tunnel ACs CE CE PE PE CE ACs CE CE PWs are bidirectional transport MPLS tunnel set up between PEs multiple PWs may be set up inside tunnel MPLS (outer) label PW (inner) label payload Native packet/frame encapsulated with 2 labels P-routers are unaware of individual customer networks 26

PWE packet format PSN / multiplexing optional RTP header optional control word (CW) higher layers payload 27

Example formats MPLS PSN tunnel label(s) PW label control word Payload L 2 TPv 3 PSN IP header (5*4 B) session ID (4 B) optional cookie (4 or 8 B) control word (4 B) payload 28

PWE Control Word 0 0 flags FRG Length Sequence Number 0 0 – Identifies packet as PW (not IP) – used to ensure ECMP mechanisms don’t interfere with proper functioning – 0001 for PWE OAM (VCCV) Flags (4 b) – not all encapsulation define – used to transport native service fault indications FRG – may be used to indicate payload fragmentation st l 00 = unfragmented 01 = 1 fragment l 10 = last fragment 11 = intermediate fragment Length (6 b) – used when packet may be padded by L 2 Sequence Number (16 b) – used to detect packet loss / misordering 29

Other Standards Bodies n ITU-T SG 13 – Y. 1411, Y. 1412, Y. 1413, Y. 1414, Y. 1415, Y. 1452, Y. 1453, X. 84 n ITU-T SG 15 – G. 769, G. 8261 n MFA Forum (MPLS – Frame Relay – ATM) – TDM over MPLS using AAL 1 IA 4. 0 – I. 366. 2 over MPLS IA 5. 0 – af-aic-0178 n MEF (Metro Ethernet Forum) – MEF 8. 0. 0 30

TDM PWs 31

TDMo. IP Protocol Processing TDM IP Packets TDM PSN Steps in TDMo. IP n The synchronous bit stream is segmented n The TDM segments are adapted n TDMo. IP control word is prepended n PSN (IP/MPLS) headers are prepended (encapsulation) n Packets are transported over PSN to destination n PSN headers are utilized and stripped n Control word is checked, utilized and stripped n TDM stream is reconstituted (using adaptation) and played out 32

TDM Structure handling of TDM depends on its structure unstructured TDM (TDM = arbitrary stream of bits) … structured TDM framed S Y N C (8000 frames per second) S Y N C channelized SYNC S Y N C (single byte timeslots) TS 2 TS 1 (1 byte) TS 3 … signaling bits … TSn multiframed frame … multiframe 33

TDM transport types Structure-agnostic transport (SATo. P – RFC 4553) • for unstructured TDM • even if there is structure, we ignore it • simplest way of making payload • OK if network is well-engineered Structure-aware transport (TDMo. IP, CESo. PSN) • take TDM structure into account • must decide which level of structure (frame, multiframe, …) • can overcome PSN impairments (PDV, packet loss, etc) 34

Structure aware encapsulations Structure-locked encapsulation (CESo. PSN) headers TDM structure Structure-indicated encapsulation (TDMo. IP – AAL 1 mode) headers AAL 1 subframe Structure-reassembled encapsulation (TDMo. IP – AAL 2 mode) headers AAL 2 minicell 35

Ethernet PWs 36

Ethernet limitations Ethernet LAN is the most popular LAN but Ethernet can not be made into a WAN n n Ethernet is limited in distance between stations Ethernet is limited in number of stations on segment Ethernet is inefficient in finding destination address Ethernet only prunes network topology, does not route so the architecture that has emerged is Ethernet private networks connected by public networks of other types (e. g. IP) LAN WAN 37

Traditional WAN architecture this model is sensible when traffic contains a given higher layer Ethernet header is removed at ingress and a new header added at egress this model is not transparent Ethernet LAN interconnect n Ethernet LANs with multiple higher layer packet types (e. g. IPv 4, IPv 6, IPX, SNA, CLNP, etc. ) can’t be interconnected n raw L 2 Ethernet frames can not be sent the Ethernet layer is terminated at WAN ingress the traffic is no longer Ethernet at all Ethernet WAN not Ethernet 38

Tunneling Ethernet frames users with multiple sites want to connect their LANs so that all locations appear to be on the same LAN this requires tunneling of all Ethernet L 2 frames (not only IP) between one LAN and another the entire Ethernet frame needs to be preserved (except perhaps the FCS which can be regenerated at egress) Ethernet X Ethernet inside X 39

Ethernet over HDLC/FR/ATM/SONET/SDH/PDH Ethernet frames can be carried over various WANs HDLC: not standardized, Cisco-HDLC FR: RFC 2427 / STD 0055 (ex 1490) ATM: RFC 2684 / (ex 1483), LANE SONET/SDH/PDH: Po. S (RFC 2615 ex RFC 1619), LAPS (X. 85/X. 86), GFP (G. 7041 ) entire Ethernet frame (or IP packet) is used as payload 40

Ethernet PW (RFC 4448) can transport tagged or untagged Ethernet frames if tagged encapsulation can be “raw mode” or “tagged mode” tagged mode processes SP tags control word is optional even if control word is used, sequence number if optional standard mode – FCS is stripped and regenerated FCS retention mode (not in 4448) allows retaining FCS 41

Ethernet Pseudowire packet (MPLS) tunnel label PW label control word Ethernet Frame usually has FCS stripped SP tag may also be stripped optional control word generation and processing of sequence number is optional 0000 reserved Sequence Number (16 b) 42

Other PWs 43

What other PW clients are there? ATM (4 different modes) frame relay SONET/SDH HDLC / PPP Fiber channel X. 25 Generic ? ? 44

PWE control protocol 45

PWE (Martini) control protocol n PWE control protocol (RFC 4447) used to set up / configure PWs n used only by PW end-points (PEs in standard model) intermediate nodes (e. g. P routers) don’t participate or see P P PE n based on LDP – – PE P P P targeted LDP is used to communicate with opposite end-point 2 new FECs for PWs new TLVs added for PW-specific functionality associates two labels with PW LDP will be discussed later 46

PWE control a PW is a bidirectional entity (two LSPs in opposite directions) a PW connects two forwarders 2 different LDP TLVs can be used – PWid FEC (128) – Generalized ID FEC (129) FEC 128 – both end-points of PW must be provisioned with a unique (32 b) value – each PW end-point independently initiates LSP set up – LSPs bound together into a single PW FEC 129 – used when autodiscovering PW end-points – each end-point has attachment identifier (AI) … 47

Generalized ID for each forwarder we have a PE-unique Attachment Identifier (AI( <PE, AI> must be globally unique frequently useful to group a set of forwarders into a attachment group where PWs may only be set up among members of a group then Attachment Identifier (AI) consists of – Attachment Group Identifier (AGI) (which is basically a VPN-id) – Attachment Individual Identifier (AII) the LSPs making up the (two directions of the) PW are < PE 1, (AGI, AII 1), PE 2, (AGI, AII 2) > and < PE 2, (AGI, AII 2), PE 1, (AGI, AII 1) > we also need to define – Source Attachment Identifier (SAI = AGI+SAII) – Target Attachment Identifier (TAI = AGI+TAII( receiving PE can map TAI uniquely to AC 48

PWE OAM 49

VCCV VC (old name for PW) connectivity verification runs inside PW (same PW label) as an associated channel differentiated by control word format (PWACH – RFC 4385) 0 0 0 1 VER RES=0 Channel Type (0 x 21 -IPv 4 0 x 57 -IPv 6) inside VCCV several different OAM mechanisms may be used: – ICMP – LSP ping – BFD – ? ? ? 50

Multisegment PW (MS-PW) 51

Multiple PSN domains P P T-PE S-PE T-PE P P P Single-Segment PW (SS-PW) requires PEs to see each other when multiple PSN domains this may not be the case Terminal-PEs interconnect via stitching-PE PW label becomes a true MPLS label (switching, swapping) when more than one S-PE need to ensure that the 2 LSPs traverse the same one 52

L 2 VPNs 53

VPWS CE AC PE PE AC CE provider network Virtual Private Wire Service is a L 2 point-to-point service it emulates a wire supporting the Ethernet physical layer set up MPLS tunnel between PEs set up Ethernet PW inside tunnel CEs appear to be connected by a single L 2 circuit (can also make VPWS for ATM, FR, etc. ) 54

VPLS PE CE AC AC CE PE for clarity only one VPN is shown PE AC CE VPLS emulates a LAN over an MPLS network set up MPLS tunnel between every pair of PEs (full mesh) set up Ethernet PW inside tunnels, for each VPN instance CEs appear to be connected by a single LAN PE must know where to send Ethernet frames … but this is what an Ethernet bridge does 55

VPLS V B CE CE B V V B CE a VPLS-enabled PE has, in addition to its MPLS functions: n VPLS code module (IETF drafts) n Bridging module (standard IEEE 802. 1 D learning bridge) SP network (inside rectangle) looks like a single Ethernet bridge! Note: if CE is a router, then PE only sees 1 MAC per customer location 56

VPLS bridge PE maintains a separate bridging module for each VPN (VPLS instance) VPLS bridging module must perform: n MAC learning n MAC aging n flooding of unknown MAC frames n replication (for unknown/multicast/broadcast frames) unlike true bridge, Spanning Tree Protocol is not used n limited traffic engineering capabilities n scalability limitations n slow convergence forwarding loops are avoided by split horizon n PE never forwards packet from MPLS network to another PE n not a limitation since there is a full mesh of PWs so always send directly to the right PE 57

Bridge - both ways CE V B CE CE B V CE V B a packet from a CE: may be sent back to a CE may be sent to a PE via a PW CE CE a packet from a PE: is only sent to a CE (split horizon) is sent to a particular CE based on 802. 1 D bridging 58

VPLS code module VPLS signaling establish PWs between PEs per VPLS autodiscovery locates PEs participating in VPLS instance obtain frame from bridge encapsulate Ethernet frames and inject packet into PW retrieve packet from PW removes PW encapsulation and forward Ethernet frame to bridge 59

L 2 VPN vs. L 3 VPN CE PE ? PE PE CE CE in L 2 VPN CEs appear to be connected by single L 2 network PEs are transparent to L 3 routing protocols CEs are routing peers in L 3 VPN CE routers appear to be connected by a single L 3 network CE is routing peer of PE, not remote CE PE maintains routing table for each VPN 60

IPLS (IP-only LAN Service) mechanisms may be simplified if Ethernet frames carry only IP traffic enables upgrade of IP routers to support VPLS-like services in this case CE devices are routers, not switches frames are still forwarded based on MAC DA (not L 3 VPN) but MAC forwarding tables updated via PW signaling, not 802. 1 D PE snoops IP and ARP frames to discover CEs connected to it creates (AC, VPN-ID, IP-addr, MAC-addr) entry creates PWs to all PEs participating in VPN-ID sends entries to these PEs Address Resolution Protocol (ARP) messages are proxied rather than being carried transparently PE searches entries it has received can support different AC types (Ethernet and FR) ARP Mediation ensures proper mapping 61

LDP vs. BGP 62

LDP vs. BGP both use TCP for reliable transport (LDP uses UDP for hellos) both are hard-state protocols both use TLV format for parameters BGP LDP multiprotocol (IPv 4, IPv 6, IPX, MPLS) MPLS only highly complex protocol simpler protocol provides routing / label distribution only label distribution built-in autodiscovery mechanism extendable for autodiscovery 63

BGP header (19 B) marker (16 B) length (2 B) type (1 B) data (variable) marker can be used for authentication (TCP MD 5 signature) length is total BGP PDU length, including header type – – OPEN (for session initialization) UPDATE (add, change and withdraw routes) NOTIFICATION (return error messages, terminate session) KEEPALIVE (heartbeat) KEEPALIVE packet consists of 19 B header only 64

BGP state machine n idle – no session (awaiting session initialization) n connect – attempting to connect to peer n active – started TCP 3 -way handshake (router busy) n open sent – have sent OPEN message n open confirm – after receiving TCP SYN for OPEN message n established – BGP session up and running 65

BGP OPEN version (1 B) my AS (2 B) hold time (2 B) BGP-ID (2 B) op len (1 B) opt parameters (variable) version (3 or 4) my AS – identifier of autonomous system hold time – max time (sec) between receipt of messages BGP ID – sender’s BGP identifier op len – length (bytes) of optional parameters opt parameters - TLVs 66

BGP UPDATE WR len withdrawn routes (2 B) (var) PA len (2 B) path attributes (var) NLRI (var) Withdrawn Routes – list of routes no longer to be used (NLRI format- see below) Path Attributes – route specific information (see next page) Network Layer Reachability Information – (classless) routing information len (1 B) prefix (variable) the NLRI is a list of address-prefixes each prefix must be masked from the left to the length specified 67

BGP UPDATE - Path Attributes flags (1 B) type code (1 B) flags O – optional/well-known bit if 1 must be recognized by all BGP implementations if W=1 and unrecognized attribute, BGP sends notification and session closed T – transitive/nontransitive bit if 1 and attribute unrecognized it is passed along, else silently ignored well-known attributes are always transitive C – complete/partial bit (for optional transitive attributes only) L – attribute length bit (=0 attribute length is 1 B, =1 length is 2 B) type code ORIGIN, AS_PATH, NEXT_HOP, MED, LOCAL_PREF, AGGREGATOR, COMMUNITY, ORIGINATOR_ID… 68

BGP NOTIFICATON error code (1 B) error subcode (2 B) data (var) all notification messages cause BGP session to close error codes include: – – – message header error open message error update message error hold timer expired state machine error other fatal error 69

LDP header (10 B) version (2 B) length (2 B) LDP-ID (6 B) messages (variable) version – presently 1 length - PDU length, excluding version and length fields LDP-ID – identifies label space of sending LDP peer – LSR-ID(4 B) globally unique LSR ID – label space ID (2 B) for per-port label spaces (zero for per-platform label spaces) messages – zero or more TLVs (see next page) 70

LDP messages type (2 B) type U length (2 B) message-ID (4 B) mandatory parameters (variable) optional parameters (variable) message code U – unknown message bit if message type unknown to receiver U=0 – receiver returns notification to sender U=1 – receiver silently ignores length - message length, excluding type and length fields Message-ID – unique ID for message (for matching with returned notification) if there are mandatory parameters, they most appear in a specific order optional parameters may appear in any order 71

LDP message types Hello (UDP, for discovery) Initialization (specifies LDP version, label space range, parameters) Keep. Alive (heart beat) Notification (error, e. g. unsupported version, unknown/malformed msg, timer expired) Address (LSR advertises its interface IP address(es) to peers) Address Withdraw (LSR revokes previously advertised interface IP address) Label Mapping (downstream LSR advertisement of a label mapping for a FEC ) Label Withdraw (downstream LSR informing that binding is revoked) Label Request (upstream LSR request for binding in downstream-on-demand mode) Label Release (upstream LSR informing that binding no longer needed) Label Abort Request (upstream LSR asks to revoke request before satisfied) 72

LDP state machine n LSR periodically transmits hello UDP messages – multicast to “all routers on subnet” group – targeted to preconfigured IP address n LSRs listen on this UDP port for hello messages n n when LSR receives hello from another LSR – it opens a TCP connection to that other LSR or (for extended discovery) – it unicast transmits a hello back to the other LSR with higher ID sends session initialization message n other LSR LDP accepts (sends keepalive) or rejects n informative or keepalive messages sent 3. 2 73

Provisioning VPLS 74

Provisioning customers may want their SP to take an active role in managing their networks Provider Provisioned VPN (PPVPN) refers to VPN for which SP participates in management and provisioning by provisioning we mean (at least) : n setting up the ACs (often manual configuration) n assigning global VPN-ID to VPN instances n discovery of all PEs that participate in a VPN instance n associating AC with VPN at PE n providing PEs with information needed to set up tunnels n configuring tunnels with necessary characteristics 75

Autodiscovery we have assumed that each PE knows which PEs participate in particular VPN instance manual configuration is problematic logistically autodiscovery refers to automatically finding all PEs in a given VPN each PE "discovers" other PEs by means of some protocol n BGP n RADIUS (Remote Authentication Dial In User Service) CE = RADIUS users, PEs = Network Access Servers (NAS) PE can authenticate CEs and find other PEs n targeted LDP (“Stokes draft”, “Stein-Delord draft” - expired) advertise FEC in LDP new TLV in label mapping message contains VPN-id, P or PE, capabilities 76

VPWS Provisioning Double Sided Provisioning each AC provisioned with local name, remote PE address, and remote name during signaling, local name is sent as SAII, remote name as TAII (AGI = null( to connect 2 ACs by a PW: local name = remote name(PWid FEC) or local name of each must be remote name of the other Single Sided Provisioning with Discovery each AC provisioned with local name (VPN-id) and AII during signaling, local name is sent as AGI to connect 2 ACs by a PW: both must have the same VPN-id only one needs to be provisioned with remote name (local name of other AC( neither needs to be provisioned with the address of the remote PE during auto-discovery procedure: each PE advertises its <VPN-id, local AII> pairs each PE compares its local <VPN-id, remote AII> pairs with <VPN-id, local AII> pairs from other PEs if match then need to connect local name sent as SAII, remote AII sent as TAII, VPN-id as AGI 77

VPLS Provisioning every VPLS instance is assigned a unique VPN-id PEs are preconfigured or find each other using auto-discovery if PE detects VPN-id to which it belongs it sets up a PW during signaling – VPN-id is send as the AGI field – SAII and TAII are set to null 78

LDP VPLS ex-“Lasserre-VKompella draft”, now draft-ietf-l 2 vpn-vpls-ldp authors: Marc Lasserre - Riverstone and Vach Kompella – Alcatel supported by Cisco, Nortel, Alcatel, Riverstone, Extreme, Luminous, Corrigent, Hatteras, Overture, RAD use LDP for – PW setup and tear-down signaling – explicit withdrawal of MACs (force relearning) full mesh of targeted LDP sessions between VPLS-enabled PEs automatically establish a full mesh of Ethernet PWs n participating PE sends an unsolicited label mapping message to every other PE, specifying VPN-ID (preferably with generalized PWid FEC element) if receiving PE accepts, it sends a label mapping message back n 79

BGP VPLS ex-“Kompella draft”, now draft-ietf-l 2 vpn-vpls-bgp authors: Kireeti Kompella, Yakov Rekhter – Juniper uses BGP 4 (with multiprotocol extensions) for: n autodiscovery (uses Route Target extended community as VPN-ID) n PW setup and tear-down (uses Network Layer Reachability Information) n force MAC relearning (uses Relearn Sequence Number TLV) protocol essentially identical to RFC 2547 bis (to be discussed later) 80

BGP VPLS signaling define demultiplexor = VPN-ID + ingress PE VPLS Edge (VE) advertises VPLS NLRIs for each VPLS instance NLRI defines demultiplexors for all PEs in VPLS instance extended attribute encodes PE capabilities if new PE joins VPLS new NLRI seamlessly adds new label coalesce to a single NLRI with temporary service disruption PE sets up PW when it receives an NLRI for VPLS to leave VPLS instance PE withdraws NLRI remote PEs remove PWs 81

Generalizations 82

Distributed (Generic) VPLS CE U-PE PE access N-PE network VPLS CE CE U-PE PE CE L 2 VPN framework allows decomposition of PE n User-Facing PE (U-PE) performs Bridge functions MAC learning, forwarding decisions n Network-Facing PE (N-PE) performs VPLS functions establishes tunnels, PWs V B U-PE is inexpensive CLE, good for MTU applications 83

Hierarchical VPLS PE VPLS MTU PE MTU VPLS HVPLS PE MTU VPLS straight VPLS has a problem – N 2 PWs are used which means N 2 LDP sessions, and N 2 floods and replications to improve scalability, can use hub-and-spoke topology if VPLS is in multi-tenant buildings, local PE is MTU HVPLS PEs are full mesh, but do not perform bridging spoke PW set up between PE and MTU (note end-point is virtual bridge) 84

L 3 VPNs 85

BGP MPLS VPNs (2547 bis) presently most popular provider managed VPN originally specified in RFC 2547, update in draft called RFC 4364 transports IPv 4 (IPv 6) traffic in MPLS tunnels uses BGP for route distribution since SPs commonly use BGP for routing 2547 is not an overlay model – CE routers at different sites are not routing peers – they do not directly exchange routing information – they don’t even need to know of each other – so customer needn’t manage a backbone or virtual backbone – no inter-site routing problems 86

BGP MPLS VPNs (cont. ) only PE routers maintain VPN information P routers needn’t maintain any customer routing information C routes either manually configured in PE or advertised to PE using BGP, OSPF, etc. PE advertises routes to remote PEs using BGP remote PEs advertise routes to their CEs using BGP, OSPF, etc. IP address overlap solved using Route Distinguisher (RD) 87

RFC 4364 (2547 bis) architecture CE not peer to CE CE peer to PE C C CE C PE P P PE CE C CE is IP router SP label ext label IP Packet Virtual router (peering) model, not tunneling PE maintains Virtual Route Forwarding table for each VPN BGP (with multiprotocol extensions) used for label distribution in order to support private IP addresses PE prepends 8 B Route Distinguisher (unique to site) to IP address 88

L 2 VPN vs. L 3 VPN n C switch connects to L 2 circuits n C router peers with SP router n BGP or LDP n BGP n all L 3 traffic types n limited to IP traffic n only Ethernet L 2 n supports different L 2 technologies n Cs responsible for routing n SP responsible for routing § “overlay model” n “peer model” n simple customer-SP interface n complex customer-SP interface n C peering scales as VPN size n C peering independent of VPN size § scaling problem n scales well 89