1 Metro Ethernet Forum OAM An Update Matt Squire Hatteras Networks

2 Scoping the Problem Bridge SONET RPR Ethernet Provider A Provider B Provider C Bridge Problem: When delivering an Ethernet service over a large, diverse network, how do you detect end-to-end connectivity problems (loss and degradation)?

3 Scoping the Problem Bridge SONET RPR Ethernet Provider A Provider B Provider C Bridge MEF is looking at multi-domain service OAM mechanisms Multi-hop path

4 Scoping the Problem Bridge SONET RPR Ethernet Provider A Provider B Provider C Bridge Multi-hop path Edge-to-edge Intra-Carrier OAM

5 Scoping the Problem Bridge SONET RPR Ethernet Provider A Provider B Provider C Bridge Multi-hop path Edge-to-edge Inter-Carrier OAM

6 Scoping the Problem Bridge SONET RPR Ethernet Provider A Provider B Provider C Bridge Multi-hop path End-to-end Customer OAM

7 Key Aspects of MEF OAM Assumes Ethernet is only common denominator –E.g Ethernet, Ethernet over SONET, RPR, etc. –Must use Ethernet framing for OAM communications Ethernet segments interconnected with forwarding entities (bridge, switch, etc.) –Connectionless, like IP –Segment can be real or virtual (see above) –Must deal with multicast and frame replication issues Must measure per service and be with data plane –Can think service = VLAN for this discussion –Out-of-band OAM not possible, not accurate with data plane –OAM mixes with user data within core (only different at edges)

8 Key Aspects of MEF OAM Initial focus on SLA metrics –Connectivity, latency, loss, jitter –Includes discovery (multicast ping) –Includes timestamped ping (connectivity test) –Includes timestamped hello (connectivity verification) Other function may follow later –Traceroute (fault isolation), RDI/AIS (fault signaling), etc. –No commitment on when/how – initial focus is Phase I –CURRENTLY NOT DEALING WITH FAULT ISOLATION Domain oriented –Supporting hierarchical domains required –Separation of customer and carrier OAM is a big thing –Domain may be intra-provider, inter-provider, customer-customer, and other

9 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | Uses a pretty generic frame format with very few fixed fields

10 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | Destination MAC address can be Well-known Multicast – for discovery and multicast tests Unicast of peer station – for unicast tests Well-known addresses default to MEF-defined but are configurable! (important later)

11 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | OAM frames are optionally tagged OAM frames are per-EVC (Ethernet Virtual Connection) [Thats a VLAN to you and me] OAM frames are tagged/not as EVC is tagged/not OAM frames for measurements follow the data path!

12 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | MEF OAM uses a well-known EtherType MEF assigned default Can be configured (important later!)

13 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | Need to come back to this one (See Security Wrinkle)

14 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | Usual versioning capability Fixed v1 for now Ignores anything higher

15 OAM Frame | Dest MAC | | Dest MAC | Source MAC | | Source MAC | | VLAN Ethertype | VLAN Tag | | (Optional) | | OAM | OAM | Version| | EtherType | Level | | | Rsvd | OpCode | Data | |Data (OpCode specific, continued)… | Pretty simple op-code functions (1/2) Connectivity Test Request/Response (layer two ping…) (3) Connectivity Verification (periodic hello…) Solicited and unsolicited connectivity checking

16 A Security Wrinkle Ethernet has the unfortunate property that packets may be sent to places they dont need to go (e.g. MAC address is not known) With OAM for a service provider environment, –OAM must not leak out of the provider to other providers or the customer –Customers and other providers must not be able to interfere with the carriers OAM To deal with this, multi-hop OAM must filter OAM at the edges of the domain

17 A Security Wrinkle Bridge Provider A OAM Barrier OAM is required to create an OAM Barrier No OAM in from the outside No OAM out from the inside Protects carrier OAM from interference and leaking An OAM domain is defined to create this barrier

18 A Security Wrinkle Hierarchical Domains 1-octet domain level in OAM frame used to implement domains Outermost customer-customer domain => 255 (0xFF) Other domains hierarchically included A inside B implies Domain A Level <= Domain B Level Level=255 L=200 L=195 L=64

19 A Security Wrinkle Hierarchical Domains Requires port filtering by OAM EtherType and Domain Level At edges of domain L If (EtherType = OAM EtherType) and (Domain Level <= L) DROP OAM PACKETS – cant inject or leak Level=255 L=200 L=195 L=64

20 A Security Wrinkle Hierarchical Domains Requires filter by OAM EtherType and Domain Level We realize this isnt great, but Hard requirement for multi-level domains with hard boundaries (e.g. no leaks) Hard requirement for OAM in same path as data (e.g. no popping to CPU) Hard requirement for working over switched networks (e.g. replication) Although not ideal, seems like the best way to meet requirements Level=255 L=200 L=195 L=64

21 Why Am I Here? MEF stuff underway, doesnt want to wait for OAM work for simple connectivity checking –Too many people want something now Mucho interest in MEF to be compatible with what.1 comes up with –Everyone hates the idea of incompatible protocols or required replacements So what can we do???

22 Why Am I Here? Easy parts –Defining MEF protocols with configurable well- known MAC address info and configurable well- known EtherType Allows migration to IEEE defined addressing via config –Other parameters also configurable Timeouts, delays, etc. –Putting as little as possible in fixed headers Best chance at compatibility is to require little –Version, domain level, op-code are only common fields –Everything else op-code specific If one-octet op-code ok, if one-octet version number ok, leaves only the domain level

23 Why Am I Here? Hard part –IF accepts Same domain methods as MEF –THEN Same frame format could be used and compatibility provided via new op-codes for additional function –IF accepts Same connectivity tests/verification as MEF –THEN Same op-codes for connectivity test and verification could be used for both Lots of people in MEF interested in seeing if we can work something out.

24 Summary MEF OAM Protocol work well underway –Wont wait Defining ping and hello –Connectivity test and verification (solicited and unsolicited ping) –Not getting into fault isolation, just detection Based on hierarchical domain model –Requirement from carriers Would be great if could quickly get consensus on fixed header aspects so MEF work could be designed as compatible (subset, phase 1, version 1, whatever) of larger project