Base Protocol Errata and Pending Issues – for RFC3588bis
Download
1 / 12

- PowerPoint PPT Presentation


  • 176 Views
  • Uploaded on

Base Protocol Errata and Pending Issues – for RFC3588bis Victor Fajardo (draft-fajardo-dime-diameter-errata-00.txt). Overview All contents of the current issues tracker in http://www.tschofenig.com:8080/diameter-interop/ has been transferred into the errata draft Includes open issues

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '' - addison


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Base Protocol Errata and Pending Issues – for RFC3588bisVictor Fajardo(draft-fajardo-dime-diameter-errata-00.txt)

IETF67 DIME WG


Slide2 l.jpg

Overview

  • All contents of the current issues tracker in http://www.tschofenig.com:8080/diameter-interop/ has been transferred into the errata draft

  • Includes open issues

    • With proposed solutions: Total of 10 issues

    • Without proposed solutions: Total of 2 issues

  • Includes useful optimization

    • Features: Total of 1

      • Not disruptive to existing implementations

IETF67 DIME WG


Slide3 l.jpg

Issue Format

  • Each Issue defined in its own section with the following format

    • Description of the problem

    • Diff between text of proposed solution and corresponding text in RFC3588

    • Description of the solution

IETF67 DIME WG


Slide4 l.jpg

Since last IETF …

  • Unresolved Issues

    • Issue 21 (Sec 2.7)

    • Issue 5 (Sec 2.8)

  • Issues with Proposed Solutions

    • Issue 1, 13, 14, 8, 9, 24, 16, 10, 17 and 18

  • Closed Issues

    • Issue 2, 3, 11, 12, 19, 7 and 6

  • Features

    • Issue 23

IETF67 DIME WG


Slide5 l.jpg

Un-Resolved Issues

Issue 21 (Sec 2.7): DiameterURI Schemes

  • Details: DiameterURI scheme does not fit models found in RFC3986, http://tools.ietf.org/wg/dime/draft-garcia-dime-aaa-uri-00.txt

  • Status: No activity

    Issue 5 (Sec 2.8): Application ID to be used by ASR/ASA, RAR/RAA, STR/STA

  • Details: Conflicting models on the relationship between base protocol and applications

    • Component vs. Non-component model

    • Component Model: Use AppId of application

    • Non-Component Model: Use AppId of zero (0)

  • Status: Very rough consensus - Use “Single Entity” model since this is the original intent of the authors and been propagated in other specifications

IETF67 DIME WG


Slide6 l.jpg

Resolved Issues

Issue 14 (Sec 2.1): Usage of the E-bit and Error Answer

  • Details: Editorial – Clarify text on which error category should use the E-bit

  • Solution: Add text in each error category regarding E-bit

    Issue 8 (Sec 2.2): Usage of E-bit in the CEA message

  • Details: Un-necessary to set the E-bit in CEA because the Result-Code combined with a well defined the CER/CEA exchange is enough

  • Solution: Move DIAMETER_UKNOWN_PEER from protocol error to permanent error category

IETF67 DIME WG


Slide7 l.jpg

Resolved Issues

Issue 9 (Sec 2.3): Inconsistent Result-code Error classification

  • Details: Several error codes are either duplicated or in the wrong category

  • Solution:

    • Result-codes that have been moved from protocol error to permanent errors:

      • DIAMETER_COMMAND_UNSUPPORTED

      • DIAMETER_INVALID_HDR_BITS

      • DIAMETER_INVALID_AVP_BITS

    • Result-codes that have been moved from permanent error to protocol errors:

      • DIAMETER_INVALID_BIT_IN_HEADER

      • DIAMETER_INVALID_MESSAGE_LENGTH

    • Result-codes that have been deprecated

      • DIAMETER_INVALID_AVP_BIT_COMBO – have same meaning as DIAMETER_INVALID_AVP_BITS

    • For backward compatibility: Result-codes which has been move from one category to another will be assigned new numeric values

IETF67 DIME WG


Slide8 l.jpg

Resolved Issues

Issue 24 (Sec 2.4): Composing Failed AVP for Invalid AVP length

  • Details: It’s not possible to copy an offending AVP to the Failed AVP when the offending AVP reports a length that is greater than the message length or less than the AVP header length

  • Solution: Allow Failed AVP to carry only the offending AVPs header with a zero-filled payload with the minimum required length

    Issue 16 (Sec 2.5): Capabilities Exchange in the Open State

  • Details: Peer FSM implies CER/CEA exchange in the OPEN state but such behavior is not specified anywhere

  • Solution:

    • Add a new sub-section to fully describe the behavior

    • CER/CEA exchange is backward compatible and non-disruptive

    • Allow only application support changes and nothing else (i.e. security schemes)

IETF67 DIME WG


Slide9 l.jpg

Resolved Issues

Issue 10 (Sec 2.6): ABNF for Vendor-Specific-Application-Id allows multiple Vendor-Ids

  • Details: Does not make sense that the ABNF allows multiple Vendor-Id in Vendor-Specific-Application-Id AVP

  • Solution: Modify the ABNF to require one instance of Vendor-Id AVP

    Issue 17 (Sec 2.9): Removal of Trailing [fixed*] avp in Command Code ABNF specification

  • Details: diameter-message ABNF specifies the use of trailing [fixed*]. This implies additional parsing requirements even if it is not used or there is no need for it.

  • Solution: Remove trailing [fixed*] from diameter-message ABNF

IETF67 DIME WG


Slide10 l.jpg

Resolved Issues

Issue 18 (Sec 2.10): Mapping between Disconnect-Cause AVP and the Reconnect Behavior

  • Details: Clarifications are needed regarding when a peers should attempt to re-connect after a DPR/DPA exchange based on the result-code provided by the Disconnect-Cause AVP

  • Solution:

    • REBOOTING: Peer MAY attempt re-connection

    • BUSY and DO_NOT_WANT_TO_TALK: Peer SHOULD NOT attempt re-connection

      Issue 1 (Sec 2.11): Advertising of Relay application-id and the Election

  • Details: Which Application-Id AVP should be used when advertising yourself as a Relay agent, AppId = 0xffffffff

  • Solution: Clearly specify that either Auth-Application-Id or Acct-Application-Id can carry a relay AppId

IETF67 DIME WG


Slide11 l.jpg

Resolved Issues

Issue 13 (Sec 2.12): Duplication of Application ID in the Header and Application Id AVPs

  • Details: Clarification on why we have multiple ways of carrying AppId information, i.e. Diameter Header and Application-Id AVPs and how do they relate to each other

  • Solution:

    • Clearly state that the AppId in the diameter header MUST be the primary method of obtaining the application identifier of a message

    • Further re-enforce that AppId in the diameter header MUST match any Application-Id AVPs present in the message

    • Clarify how Vendor-Specific-Application-Id must be treated

IETF67 DIME WG


Slide12 l.jpg

Optimization

Issue 23 (Sec 3.1): Predictive Loop Avoidance

  • Details: A routing loop that occurs in a diameter node can already be detected and possibly avoided by its previous-hop

  • Solution: The previous-hop can check to see if the next-hop for a message is already present in the messages’ Route-record AVP. If so, it can attempt to forward to an alternate route or send an DIAMETER_UNABLE_TO_DELIVER

IETF67 DIME WG