IETF59 PWE3 Workgroup 01Mar03 Setup of TDM Pseudowires draftvainshteinpwe3tdmcontrolprotocolextensio

1
IETF-59PWE3 Workgroup 01-Mar-03Setup of TDM
Pseudowires draft-vainshtein-pwe3-tdm-control-pr
otocol-extension-00.txtdraft-galtzur-l2tpext-tdm-
00.txt

• Sasha Vainshtein, Sharon Galtzur

2
TDM Pseudowires

• A wide range of services
• Specified in draft-ietf-pwe3-tdm-requirements-04.t
  xt
• Two basic emulation modes and multiple sub-modes
• Structure-agnostic - the WG is progressing a
  single document on the Standards Track
• Covers emulation of T1 (a.k.a. DS1), E1, T3
  (a.k.a. DS3) and E3 circuits
• Supports an optional "octet-aligned" mode for T1
• Structure-aware
• Covers emulation of NxDS0 circuits with and
  without CAS
• The WG considers two incompatible "flavors as
  Informational documents
• Raw (a.k.a. frame-locked) - draft-ietf-pwe3-cesops
  n-00.txt
• AAL1-based (a.k.a. adapted) - draft-ietf-pwe3-tdmo
  ip-00.txt

3
TDM Pseudowires (2)

• Many configurable parameters must be agreed
  between the PW end points during the setup
• Attachment circuit type
• NxDSo circuits with CAS originating in different
  trunks are incompatible
• Attachment circuit bit-rate
• Must be the same at both end points
• Sometimes (but not always! )can be unambiguously
  derived from the attachment circuit type
• Packet payload size
• All encapsulation documents postulate the same
  size in both directions
• Default payload size can always be used
• Usage of RTP header
• Is omitted by default
• If used, one of two time stamp generation modes
  can be selected

4
TDM Pseudowires (3)

• The objective map all this variety of circuit
  types, bit rates, encapsulation modes etc. onto a
  small set of parameters of the PW FEC
• The solution must be equally applicable to PWid
  FEC and Generalized PW FEC
• Already defined PW FEC elements should be reused
  as much as possible
• Setup of "simple" TDM PWs should be as simple as
  possible
• A simple TDM PW is structure-agnostic with all
  configurable encapsulation parameters set to
  mandatory default values
• Similar solutions should be used for MPLS and
  L2TPv3 transport
• Usually handled at two different WGs
• Exchange of the Attachment circuit status
• Handled in the data plane

5
TDM PW FEC (1)

• End point identification is out of scope
• This is where PWid FEC and Generalized PW FEC
  differ
• Common PW FEC elements to use
• Service Type
• The Control Word flag - must be always set
• Already defined interface parameters
• TDM/CEP bit-rate
• CEP payload bytes (can we rename it to TDM/CEP
  payload bytes?) - can be omitted if the
  corresponding default is used
• A single new interface parameter - TDM Options
• Covers all the remaining aspects of the PW Setup
• Can be omitted for structure-agnostic emulation
  without RTP

6
TDM PW FEC (2)

• Service Types vs. Attachment Circuit bit-rates
• In the structure-agnostic case are mutually
  interchangeable
• The current document uses multiple service type
  code points even for structure-agnostic emulation
• In most cases the service bit rate can be omitted
• Only required if octet-aligned T1 encapsulation
  mode is used
• An alternative would be a single SAToP service
  type code point with mandatory bit-rate parameter
• WG input is solicited on this issue
• For structure-aware emulation
• The service type code points distinguish between
  basic NxDS0 and trunk-specific NxDS0 with CAS for
  different trunks
• The bit-rate reflects the number of timeslots (N)
  in the attachment circuit and cannot be omitted

7
TDM PW FEC (3)

• TDM Options
• 0 1 2
  3
• 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
  3 4 5 6 7 8 9 0 1
• -----------------------
  ---------
• Parameter ID Length RDF
  RSVD-1
• -----------------------
  ---------
• 0 PT RSVD-2
  FREQ
• -----------------------
  ---------
• SSRC
  
• -----------------------
  ---------
• A variable length interface parameter
• Only 4 bytes if RTP is not used
• 8 bytes if SSRC check is not used
• Mandatory for
• Structure-aware emulation (to distinguish between
  the flavors)
• RTP-using encapsulations
• Parameter ID to be assigned by IANA

8
What Next

• How to progress this work
• Probably too late to be merged with the PWE3
  Control Protocol and IANA Allocation drafts
• Proposal adopt as a separate WG item and proress
  with the rest of the TDM work
• Issue should it remain MPLS-only, or should it
  be merged with the corresponding L2TPv3
  extensions draft?
• The WG input is solicited

9
Questions?