Subject: [Speermint] Design Team Comments: draft-ietf-speermint-architecture-08

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 03 Jun 2009 14:18:32 -0400

>From our design session today, which Adam could not attend.

Here are our comments for the authors to review and act on.  Please perform
an update to 09 prior to the cutoff for the Stockholm IETF meeting.  After
these changes, this document is probably ready or nearly ready for WGLC.

General: need reference to RFC 5486 (Terminology)

Section 1: no comments

Section 2: 
    - Eliminate Figure 1
    - Eliminate entire section  does not serve a useful purpose

Section 3, Comments on Figure:
    - Increase the space between the SSP domains
    - Move existing DNS block down to be between / on the same level as the
LUF
    - Change existing DNS block, change text inside to: ENUM, TN DB
    - Add a new box below that block between the LRF, and make that box
contain: DNS, IP Addrs., Etc. (and make connecting lines from this to each
LRF)
    - Add connecting lines between the SBEs
    - Add connecting lines between the DBEs
    - Within each SSP domain, add a connecting line between the SBE and the
SSP¹s LUF and LRF
    - Change ³Orginating SSP² and ³Terminating SSP² to ³SSP 1² and ³SSP 2²
    - Remove ³SF² and ³MF² and just keep SBE and DBE inside the boxes
   
    - Remove all text after the figure, and insert a reference to RFC 5486
as follows:
    ³For further details on the elements and functions described in this
figure, please refer to [RFC 5486].²

    - Add a new sub-section to section 3, which describes the relationships
between various functions/elements, as follows:
        -- An SBE can contain an SF function
        -- An SF can perform LUF and LRF functions
        -- As an additional consideration, a Session Border Controller (cite
new SBC RFC here), can contain an SF, SBE and DBE, and may perform the LUF
and LRF functions.
        -- The following functions can communicate as follows, depending
upon various real-world implementations:
            - SF can communicate with LUF, LRF, SBE, and SF
            - LUF can communicate with SF and SBE
            - LRF can communicate with SF and SBE

Section 4:
    - Hyphenate ³Inter-Domain² in the section title
    - Capitalize ³originating² to ³Originating²
    - Change all those steps as follows:
     1. Determine the target SSP via the LUF.
     2. Determine the address of the SF of the target SSP via the LRF.
     3. Establish the session.
     4. Exchange the media, which could include voice, video, text, etc.
    - Fix the following sentences in that section to suit the new numbers
above.

Section 5: 
    - Make sure each section title has leading caps.  For example, 5.1.1.1
should be Target Address Analysis
    - 5.1.1.1: 
        -- Paragraph 1, delete ³Note that the SSP may also consult any
manner of private data sources to make this determination.²
        -- Paragraph 2, re-word as follows:
    If the target address does not represent a resource inside the
originating SSP's administrative domain or federation of domains, then the
originating SSP performs a Lookup Function (LUF) to determine a target
address, and then it resolves the call routing data by using the Location
Routing Function (LRF).
        -- Please remove any detailed discussion beyond above of the LRF 
and move to the relevant LRF section.
        -- Please move the SIP redirect section 5.1.2.3 into this section
    - Remove section 5.1.1.3, Infrastructure ENUM
    - 5.1.2, at the end, add: ³The following sections define mechanisms
which may be used by the LRF.  These are not in any particular order and,
importantly, not all of them may be used.²
    - 5.1.2.1, change title to ³DNS Resolution² (dropping ŒSIP¹)
    - 5.1.2.1, strike the first sentence, as out-of-scope (policy).
    - 5.1.2.1, strike the sentence ³Note that these are queries of records
in the global DNS.²
    - Change title of section 5.1.1.2 to ³ENUM Lookup² and remove references
to  any specific kind of ENUM (end user, infrastructure, or private)
    - After 5.1.2.2 (Routing Table), add a new section (5.1.2.3), to
describe the new box in the architecture diagram.  The box was DNS, IP
Addresses, Etc.  This section should describe other methods not already
defined, such as codec-based routing, method-based routing, time of day
routing, least cost routing source-based routing.
    - 5.1.3, change the title to ³The Signaling Path Border Element (SBE)²
    - 5.1.3, reword 2nd paragraph, 2nd sentence as follows: ³The optional
termination and re-initiation of calls may be performed by the signaling
path element (SBE), or other signaling elements.³
    - 5.1.3, end of 3rd paragraph, you have an ³and² before ³SIP security²
--> so take out that ³and²: ³... SIP header normalization, SIP security,
privacy, and encryption.²  (note also comma added after privacy)
    - 5.1.3.1.2, TLS, delete entire section
    - 5.2, rename section to ³Target SSP Procedures²
    - 5.2.1, delete entire section (out of scope -> DRINKS)
    - 5.2.2, change title to ³The Ingress Signaling Path Border Element
(SBE)²
    - 5.2.2.1, delete 2nd paragraph
    - 5.2.2.1, changes 1st paragraph, delete last two sentences (³For these
requests, there should be no remaining Route header field values. For
in-dialog requests, the receiving SSP can verify that it corresponds to the
top-most Route header field value.²)
    - 5.2.2.2, change 2nd paragraph, 2nd sentence, to: ³For example, when a
request is rejected because the originating SSP is not authorized to peer,
the receiving SSP should respond with a 403 response with the reason phrase
"Unsupported Peer".²
    - 5.3: This duplicates section 5.2, so delete section.
    - 5.4, rename section title to ³Data Path Border Element (DBE)²
    - 5.4, please also add a reference to RFC 5486 in the first sentence,
such as ³As defined in [RFC 5486], the purpose of the MF...²
    - 5.5, Policy, delete entire section (we¹ll come back to policy later in
another draft)
    - 6, delete section (may be good content for an implementation-specific
draft later on, but not needed here)
    
    - GENERAL: The reference numbers in Normative and Informative references
ALL need to be checked ‹ a number of these are incorrect.  Need to change
all references to the type [RFCXXXX].  Also, prune any unused references.

    - Add a new section after Section 9 (IANA considerations), named
³Contributors², and add:
        The following people made significant textual contributions to and
provided significant in-depth review of this document:
        Hadriel Kaplan, Acme Packet ([email-masked])
        Jason Livingood, Comcast ([email-masked])
        David Schwartz, Kayote Systems ([email-masked])
        Rich Shockey, Unaffiliated ([email-masked])

//END OF COMMENTS ON THIS DRAFT//

--> UNRELATED TO DO ITEM:  Create a new draft (anyone?) on Call Control and
Media Control Deployment Options using content from Section 6 of
http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-08.txt
, if interested:

6. Call Control and Media Control Deployment Options

   The peering functions can be deployed along the following two dimensions
   depending upon how the signaling and the media functions along with IP
layer 
   are implemented:

   Composed or Decomposed:  Addresses the question whether the media must
flow 
   through the same physical and geographic elements as SIP dialogs and
sessions.  

   Centralized or Distributed:  Addresses the question whether the logical
and 
   physical interconnections are in one geographical location or distributed
to 
   multiple physical locations on the SSP's network.

   In a composed model, SF and MF functions are implemented in one peering
logical 
   element.  
    
             Provider A                        Provider B
             ----------   .               .   ----------
            /           \ .               .  /          \
           |            | .       _       . |            |
           |       +----+ .     /   \_    . +----+       |
           |       | SF |<-----/     \------| SF |       |
           |       +-+--+ .   /Transit\   . |    |       |
           |         | |  .  /   IP    \  . |    |       |
           |       +-+--+ .  | Provider|  . |    |       |
           |       | MF |<~~~| (Option)|~~~~| MF |       |
           |       +----+ .   \        /  . +----+       |
           |            | .    \ __ _ /   . |            |
            \_________ /  .               .  \________ _/
             ----------                       ----------
    
   --- Signal (SIP)
   ~~~ Bearer (RTP/IP)
   ... Scope of peering
                   
                   Figure 3: Decomposed v. Collapsed Peering
 
   The advantage of a collapsed peering architecture is that one-element
solves 
   all peering issues. Disadvantage examples of this architecture are single
point 
   of failure, bottleneck, and complex scalability.

   In a decomposed model, SF and MF are implemented in separate peering
logical 
   elements. SFs are implemented in a proxy and MFs are implemented in
another 
   logical element.  The scaling of signaling versus scaling of media may
differ 
   between applications.  Decomposing allows each to follow a separate
migration 
   path.  

   This model allows the implementation of M:N model where one SF is
associated 
   with multiple peering MF and one peering MF is associated with multiple
SFs. 
   Generally, a vertical protocol associates the relationship between a SF
and a 
   MF. This architecture reduces the potential of a single point of failure.
It 
   allows separation of the policy decision point and the policy enforcement
   point. An example of disadvantages is the scaling complexity because of
the M:N 
   relationship and latency due to the vertical control messages between
entities. 

//end//

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 3 Jun 2009 14:47:54 -0400

Jason,

Seeing as I drew that picture in section 2.....

That section could likely be replaced by a reference to the Use Cases
document which did not exist at first.

The reference could be a sentence at the beginning of what is now
Section 3.

Mike

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Livingood, Jason
Sent: Wednesday, June 03, 2009 2:19 PM
To: Adam Uzelac; [email-masked]
Subject: [Speermint] Design Team
Comments:draft-ietf-speermint-architecture-08

>From our design session today, which Adam could not attend.  

Here are our comments for the authors to review and act on.  Please
perform an update to -09 prior to the cutoff for the Stockholm IETF
meeting.  After these changes, this document is probably ready or nearly
ready for WGLC.

Section 1: no comments

Section 2: 
    - Eliminate Figure 1
    - Eliminate entire section - does not serve a useful purpose

Section 3, Comments on Figure:
    - Increase the space between the SSP domains
    - Move existing DNS block down to be between / on the same level as
the LUF
    - Change existing DNS block, change text inside to: ENUM, TN DB
    - Add a new box below that block between the LRF, and make that box
contain: DNS, IP Addrs., Etc. (and make connecting lines from this to
each LRF)
    - Add connecting lines between the SBEs
    - Add connecting lines between the DBEs
    - Within each SSP domain, add a connecting line between the SBE and
the SSP's LUF and LRF
    - Change "Orginating SSP" and "Terminating SSP" to "SSP 1" and "SSP
2"
    - Remove "SF" and "MF" and just keep SBE and DBE inside the boxes
   
    - Remove all text after the figure, and insert a reference to RFC
5486 as follows:
    "For further details on the elements and functions described in this
figure, please refer to [RFC 5486]."

    - Add a new sub-section to section 3, which describes the
relationships between various functions/elements, as follows:
        -- An SBE can contain an SF function
        -- An SF can perform LUF and LRF functions
        -- As an additional consideration, a Session Border Controller
(cite new SBC RFC here), can contain an SF, SBE and DBE, and may perform
the LUF and LRF functions.
        -- The following functions can communicate as follows, depending
upon various real-world implementations:
            - SF can communicate with LUF, LRF, SBE, and SF
            - LUF can communicate with SF and SBE
            - LRF can communicate with SF and SBE

Section 4:
    - Hyphenate "Inter-Domain" in the section title
    - Capitalize "originating" to "Originating"
    - Change all those steps as follows:
     1. Determine the target SSP via the LUF.
     2. Determine the address of the SF of the target SSP via the LRF.
     3. Establish the session.  
     4. Exchange the media, which could include voice, video, text, etc.

    - Fix the following sentences in that section to suit the new
numbers above.

Section 5: 
    - Make sure each section title has leading caps.  For example,
5.1.1.1 should be Target Address Analysis
    - 5.1.1.1: 
        -- Paragraph 1, delete "Note that the SSP may also consult any
manner of private data sources to make this determination."
        -- Paragraph 2, re-word as follows:
    If the target address does not represent a resource inside the
originating SSP's administrative domain or federation of domains, then
the originating SSP performs a Lookup Function (LUF) to determine a
target address, and then it resolves the call routing data by using the
Location Routing Function (LRF).  
        -- Please remove any detailed discussion beyond above of the LRF
- and move to the relevant LRF section.
        -- Please move the SIP redirect section 5.1.2.3 into this
section
    - Remove section 5.1.1.3, Infrastructure ENUM
    - 5.1.2, at the end, add: "The following sections define mechanisms
which may be used by the LRF.  These are not in any particular order
and, importantly, not all of them may be used."
    - 5.1.2.1, change title to "DNS Resolution" (dropping 'SIP')
    - 5.1.2.1, strike the first sentence, as out-of-scope (policy).
    - 5.1.2.1, strike the sentence "Note that these are queries of
records in the global DNS."
    - Change title of section 5.1.1.2 to "ENUM Lookup" and remove
references to  any specific kind of ENUM (end user, infrastructure, or
private)
    - After 5.1.2.2 (Routing Table), add a new section (5.1.2.3), to
describe the new box in the architecture diagram.  The box was DNS, IP
Addresses, Etc.  This section should describe other methods not already
defined, such as codec-based routing, method-based routing, time of day
routing, least cost routing source-based routing.
    - 5.1.3, change the title to "The Signaling Path Border Element
(SBE)"
    - 5.1.3, reword 2nd paragraph, 2nd sentence as follows: "The
optional termination and re-initiation of calls may be performed by the
signaling path element (SBE), or other signaling elements."
    - 5.1.3, end of 3rd paragraph, you have an "and" before "SIP
security" --> so take out that "and": "... SIP header normalization, SIP
security, privacy, and encryption."  (note also comma added after
privacy)
    - 5.1.3.1.2, TLS, delete entire section
    - 5.2, rename section to "Target SSP Procedures"
    - 5.2.1, delete entire section (out of scope -> DRINKS)
    - 5.2.2, change title to "The Ingress Signaling Path Border Element
(SBE)"
    - 5.2.2.1, delete 2nd paragraph
    - 5.2.2.1, changes 1st paragraph, delete last two sentences ("For
these requests, there should be no remaining Route header field values.
For in-dialog requests, the receiving SSP can verify that it corresponds
to the top-most Route header field value.")
    - 5.2.2.2, change 2nd paragraph, 2nd sentence, to: "For example,
when a request is rejected because the originating SSP is not authorized
to peer, the receiving SSP should respond with a 403 response with the
reason phrase "Unsupported Peer"."
    - 5.3: This duplicates section 5.2, so delete section.
    - 5.4, rename section title to "Data Path Border Element (DBE)"
    - 5.4, please also add a reference to RFC 5486 in the first
sentence, such as "As defined in [RFC 5486], the purpose of the MF..."
    - 5.5, Policy, delete entire section (we'll come back to policy
later in another draft)
    - 6, delete section (may be good content for an
implementation-specific draft later on, but not needed here)
    
    - GENERAL: The reference numbers in Normative and Informative
references ALL need to be checked - a number of these are incorrect.
Need to change all references to the type [RFCXXXX].  Also, prune any
unused references.

    - Add a new section after Section 9 (IANA considerations), named
"Contributors", and add:
        The following people made significant textual contributions to
and provided significant in-depth review of this document:
        Hadriel Kaplan, Acme Packet ([email-masked])
       Jason Livingood, Comcast ([email-masked])
        David Schwartz, Kayote Systems ([email-masked])
       Rich Shockey, Unaffiliated ([email-masked])

--> UNRELATED TO DO ITEM:  Create a new draft (anyone?) on Call Control
and Media Control Deployment Options using content from Section 6 of
http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-08
.txt, if interested:

   The peering functions can be deployed along the following two
dimensions 
   depending upon how the signaling and the media functions along with
IP layer 
   are implemented:  

   Composed or Decomposed:  Addresses the question whether the media
must flow 
   through the same physical and geographic elements as SIP dialogs and
sessions.  

   Centralized or Distributed:  Addresses the question whether the
logical and 
   physical interconnections are in one geographical location or
distributed to 
   multiple physical locations on the SSP's network.  

   In a composed model, SF and MF functions are implemented in one
peering logical 
   element.  
    
             Provider A                        Provider B 
    
   --- Signal (SIP) 
   ~~~ Bearer (RTP/IP) 
   ... Scope of peering 

   The advantage of a collapsed peering architecture is that one-element
solves 
   all peering issues. Disadvantage examples of this architecture are
single point 
   of failure, bottleneck, and complex scalability.  

   In a decomposed model, SF and MF are implemented in separate peering
logical 
   elements. SFs are implemented in a proxy and MFs are implemented in
another 
   logical element.  The scaling of signaling versus scaling of media
may differ 
   between applications.  Decomposing allows each to follow a separate
migration 
   path.  

   This model allows the implementation of M:N model where one SF is
associated 
   with multiple peering MF and one peering MF is associated with
multiple SFs. 
   Generally, a vertical protocol associates the relationship between a
SF and a 
   MF. This architecture reduces the potential of a single point of
failure. It 
   allows separation of the policy decision point and the policy
enforcement 
   point. An example of disadvantages is the scaling complexity because
of the M:N 
   relationship and latency due to the vertical control messages between
entities. 

//end//