1 / 12

Overview

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

mcgregorb
Download Presentation

Overview

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

More Related