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

Base Protocol Errata and Pending Issues for RFC3588bis Victor Fajardo draft-fajardo-dime-diameter-errata-00.txt - 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 'Base Protocol Errata and Pending Issues for RFC3588bis Victor Fajardo draft-fajardo-dime-diameter-errata-00.txt' - 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


ad