UNI 1'0 Updates

1
UNI 1.0 Updates

• OIF2003.055.1
• dimitri.papadimitriou_at_alcatel.be

2
IETF Status

• GMPLS Signalling gt Proposed Standard (RFC 3471)
• GMPLS RSVP-TE gt Proposed Standard (RFC 3473)
• GMPLS Extensions for Sonet/SDH gt Stable since
  Oct02 (under IESG Last Call)
• LMP v07.txt gt Stable since Sept02 (soon under
  IESG Last Call)

3
Introduction

• Assumption three levels of updates are needed in
  UNI 1.0
• Code-points
• Object and messages
• Change functional scope (UNI 2.0)
• First two do NOT imply any functional revision
  they are really vital for UNI 2.0 next steps
  achievements

4
Why Alignment ?

• Interoperability (with GMPLS compliant
  implementations)
• Avoid interworking functions were not required
  lot of other things to do
• Software implementation and maintenance for
  vendors gt complexity in maintaining several
  flavours of the same piece of software
• Complex interaction with other standard bodies
  no gain by maintaining our own set of code-points
  and values

5
Real life of a Developer

• All of them arent SDH/Sonet experts should they
  ?
• Look at gmpls-sonet-sdh-02.txt
• already misunderstandings
• Look at gmpls-sonet-sdh-07.txt
• next step in misinterpretation
• Then interwork between UNI and NNI ! Are we
  cultivating unneeded complexity ?
• sometimes YES

6
In this long list

• G-PID values
• LSP Encoding Type values
• Label at OIF (Channel Sub-Channel) no separate
  sub-objects
• IF_ID RSVP Hop Object
• ERROR_SPEC (6/1) and support of IF_ID ERROR_SPEC
  object (6/3, 6/4)
• Rationale for NSAP usage ?

7
ResvConf

• from a MAY (SHOULD) it has become a MUST and
  introduce a real problem when crossing specific
  environments (sync)
• Mandate this feature decrease the
  inter-operability level of OIF UNI Specification
• expectations
• optional as per RFC 2205
• not related to data plane any rationale
• for alarm use Admin_Status object

8
UNI-N Deletion

• Expectations network initiated deletion to be
  supported FINE !
• Why symmetric behavior ? Specific processing for
  Source UNI-N and Destination UNI-N initiated
  deletion
• Do we have to maintain in UNI 1.0 functions that
  wont be demoed ?
• why not just use a Notify message to reach the
  connection initiator ?

9
Next Steps

• Actions to be done listed in OIF2003.55/51 gt
  motion(s)
• Who ? Support in delivering a revisited version
  of the UNI Spec gt OIF UNI 1.0 Release 2
• This version should also be review by IETF CCAMP
  WG ( gain credibility)