From:
speermint-bounces at ietf.org [mailto:speermint-bounces at ietf.org] On Behalf Of Livingood,
Jason
Sent: Wednesday, June 03, 2009 2:19 PM
To: Adam Uzelac; speermint at ietf.org
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.
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 (hkaplan at acmepacket.com)
Jason
Livingood, Comcast (jason_livingood at cable.comcast.com)
David Schwartz, Kayote Systems
(david.schwartz at kayote.com)
Rich Shockey,
Unaffiliated (richard at shockey.us)
//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//
