Transcript Metadata - IETF Tools

Metadata Considerations
draft-rijsman-sfc-metadata-considerations-00
Service Function Chaining Working Group
IETF 89 - London - March 2014
Authors: Bruno Rijsman, Jerome Moisand
Presenter: Ross Callon
SERVICE FUNCTION CHAINING ABSTRACTIONS
IETF SERVICE FUNCTION CHAINING (SFC) WORKGROUP
SC Service Chain
SF
SF
SF
SFI
SFN
SFI
SFN
SFI
SC
SFN
SFI
Service
Classifier
SFN
SFI
SPS
SFN
Service Path Segment
SP Service Path
2
Presented at IETF London 2014
Service
Function
Service
Function
Instance
SFI
SFN
SC
SFI
SFN
Service
Function
Node
WHAT IS METADATA?
Metadata is "data about data"
SC
data
SFI
SFI
SFI
SFN
SFN
SFN
data
data
metadata
3
data
metadata
metadata
data
data
data
data
metadata
Presented at IETF London 2014
data
SC
data
metadata
data
data
metadata
Data in flow 1
Metadata about flow 1
Data in flow 2
Metadata about flow 2
METADATA USE CASE 1: SUBSCRIBER-AWARENESS
CONTEXTUAL INFORMATION WHICH IS NOT LOCALLY AVAILABLE
Per subscriber accounting and billing
PCRF
SC
PGW
data
data
data
data
data
SFI
SFI
SFN
SFN
data
accounting-id
4
Presented at IETF London 2014
data
Data
Metadata
METADATA USE CASE 2: APPLICATION-AWARENESS
AVOID REPETITION OF EXPENSIVE OPERATION (E.G. DPI)
Application-aware services
No need to re-apply DPI
Deep Packet Inspection (DPI)
data
SFI
SFI
SFI
SFN
SFN
SFN
data
data
data
data
application-id
5
Presented at IETF London 2014
data
Data
Metadata
METADATA USE CASE 3: FINE-GRAINED POLICIES
SUPPORT FINE-GRAINED POLICIES WITHOUT NEEDING MANY CHAINS
One chain with fine-grained policies
RADIUS
SC
BNG
data
data
data
data
data
SFI
SFI
SFN
SFN
data
data
bandwidth-cap = 34 Mbps
data
data
data
data
data
data
data
bandwidth-cap = 17 Mbps
6
Presented at IETF London 2014
Data
Metadata
Data
Metadata
METADATA SIGNALING - ARCHITECTURAL OPTIONS
Option 1: In-band marking
Option 2: Application Layer Headers
Attach metadata to each packet
E.g. HTTP extension headers
SFI
SFI
SFI
SFI
SFI
SFI
SFN
SFN
SFN
SFN
SFN
SFN
data
data
data
data
data
HTTP Request
data
metadata
metadata
7
Presented at IETF London 2014
GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml
User-Agent: Mozilla/5.0 (Windows NT
6.1)
Accept-Encoding: gzip,deflate
Accept-Language: en-US,en;q=0.8
Metadata-Subscriber-ID: 12345
Metadata-Session-ID: 67890
data
METADATA SIGNALING - ARCHITECTURAL OPTIONS
Option 3:
Congruent Out-of-Band Signaling
Option 4:
Non-Congruent Out-of-Band Signaling
Control Plane: Metadata Signaling
metadata
metadata
SFI
SFN
data
data plane
control plane
data
data plane
SFI
data
control plane
SFN
data
data
SFI
SFN
data
Data plane
metadata
Control plane
8
Presented at IETF London 2014
metadata
SFI
SFI
SFI
SFN
SFN
SFN
data
data
data
data
data
data
METADATA SIGNALING - ARCHITECTURAL OPTIONS
Option 5:
Hybrid: In-Band Session-ID + Out-of-Band Signaling
SFI
SFN
data plane
control plane
SFI
SFN
data plane
SFI
control plane
SFN
Data plane
data
session-id
session-id  metadata mapping
9
Presented at IETF London 2014
Control plane
METADATA CHALLENGES
•
•
•
•
•
•
•
•
•
•
•
•
•
Support for metadata-unaware service function
Preserving metadata through metadata-unaware service functions
Metadata encoding (fixed length versus TLV)
Availability and performance of the control plane
Synchronization between the control plane and the data plane
Distributing metadata only to interested service functions
Associating data plane flow with control plane signaling
Layering considerations (separate path layer and service layer)
Load balancing and symmetry
High availability
Geographic dispersion
Multiple sources of metadata
Extensibility
10
Presented at IETF London 2014
CONCLUSIONS
• Need standardization for multi-vendor interoperability
• Multiple approaches
 In-band marking
 Out-of-band signaling (congruent or non-congruent)
 Hybrid approach
• Many challenges with each approach
• No single approach is obvious winner
 Different approaches for different use cases?
 Hybrid approach good match for mobile and fixed broadband
• Keep service path signaling and metadata signaling separate
 Separate layers, separate headers, separate protocols
 Don't need to be standardized at the same time
11
Presented at IETF London 2014