Subject: RE: [Sipping] Draft: Functions of Current SBCs

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 24 Feb 2005 15:11:24 -0500

Brian,
 
I am trying to gain some clarity in definitions.  Terms get thrown
around rather loosely.  Perimeter or edge for one protocol or layer may
be entirely somewhere else for another protocol or layer.  Yet some of
this discussion seems to assume that they are geographically or perhaps
topologically found in the same box or adjacent boxes.  I'm not so sure.
Such assumptions may not apply in all cases, and it may not be good to
design in such constraints.  Assumptions about IP addresses may not
hold.  Signaling and media may need to take different routes.  I don't
have a clear picture yet in my head, but I wouldn't want to get boxed
into one way of doing things.
 
Mike

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Brian Rosen
	Sent: Thursday, February 24, 2005 2:19 PM
	To: Michael Hammer (mhammer); [email-masked]; 'Medhavi
Bhatia'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	I don't think I agree.

	A carrier (ITSP) deploys an SBC to protect his network from his
customers and his peers.

	An enterprise/residence/... deploys an SBC to protect his
internal domain from any caller from any external domain.

	We observe that there are more similarities than differences,
but there are differences.

	It is pretty unusual for an enterprise/residential network to
deploy an SBC anywhere other than the perimeter of their network.

	It is pretty unusual for a carrier to deploy an SBC anywhere
other than the perimeter of the "service" (voice/video/text/...) part of
their network.

	In both cases, you may have some packet level boxes between the
SBC and the actual edge of the network, but logically, they are both the
last box facing the rest of the world.

	Brian

________________________________

	From: Michael Hammer (mhammer) [mailto:[email-masked]] 
	Sent: Thursday, February 24, 2005 1:53 PM
	To: [email-masked]; Brian Rosen; Medhavi Bhatia; Richard
Fogel; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	Henry,

	One of the issues is what we mean by network or perimeter.  From
the perspective of the network transport mechanisms, a SIP sending
device may be centered in the data network somewhere multiple router
hops away from the data network edge.  But, from the perspective of the
SIP application layer, the SIP sending device may be the last such
device to operate on SIP (think TLS connection) within that network
before egressing that data network to another data network.  Put another
way, it is perimeter for the ITSP, but not perimeter for the ISP, both
of which might be the same SP.  The co-location topologically of SBC
with NAT or FW begs for a picture to be drawn.  Else, we are blind men
describing an (white?) elephant.

	Another aspect is, from the SIP application layer perspective,
one type of ITSP SIP perimeter device is used to peer with another ITSP
SIP perimeter device.  Another type of perimeter device interfaces with
a customer SIP perimeter device (e.g. IP-PBX) or simply a customer IAD
or SIP IP Phone.  Client side v. Network side sort of captures this
facet, but I am leery of the term client that slides too easily into UAC
v. UAS, v. Proxy connotations.  Hard to differentiate, when there is a
peer-to-peer aspect to this.  Because of mobility, perhaps there really
is no distinction between customer and ITSP peer interfaces.

	The SBC concept seems to infer that there is an "inside" versus
"outside".  With mobility the devices supposedly on the "inside" may
really be on the "outside" from the data network perspective.
Ultimately, it seems a given SIP message is addressed to a particular
SIP peer and pops up out of the data network at that peer's IP/port
doorstep.  If the SIP device does not have any relationship to the
message sender, it can forward/redirect on to another device or ignore
that request.  It would seem this devolves into SIP devices ensuring
that the proper sequence of SIP devices is traversed so that SIP
functions are performed in the proper order.  Leading back to what SIP
border functions are needed.  These may depend on whether the
relationships are native or non-native.

	Mike

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: Thursday, February 24, 2005 12:14 PM
		To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel';
[email-masked]
		Subject: RE: [Sipping] Draft: Functions of Current SBCs

		>How about client side and network side?

		1. The intermediaries used in carrier networks (often
referred to as SBC in a confusing manner) could be called "Network based
Session Controllers" or NSC.

		2. The intermediaries at the perifery of private IP
networks, colocated with the NAT/FW could be called "Perimeter Session
Controllers" or PSC.

		Any other, more accurate names?

		Thanks, Henry

________________________________

		From: Brian Rosen [mailto:[email-masked]] 
		Sent: Thursday, February 24, 2005 10:43 AM
		To: [email-masked]; 'Medhavi Bhatia'; 'Richard
Fogel'; [email-masked]
		Subject: RE: [Sipping] Draft: Functions of Current SBCs

		Henry

		As always, you wield a sharp sword.  I think you are
correct, we need to differentiate a client side SBC from a network side
SBC and we need names.

		How about client side and network side?

		Brian

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: Thursday, February 24, 2005 10:45 AM
		To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
		Subject: RE: [Sipping] Draft: Functions of Current SBCs

		Medhavi,

		It appears the location of such intermediaries makes the
critical difference:

		1. SBC placed in the network (in the C.O.) of the
carrier, or 

		2. A perimeter device (such as Borderware or SIP media
Proxy - these are product names ) that is collocated as CPE with the NAT
and Firewall. This co-location changes many security aspects (we need to
specify which) and also the media performance, as well as bandwidth
consumption. Multi-homing is an issue here, not to forget.

		I suggest we should always make this distinction. Maybe
someone proposes some definitions or names for each.

		Thanks, Henry

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 24 Feb 2005 17:10:24 -0500

Mike, the border's at various layers may not coincide. I think you make that
point quite well. ASPs/ITSPs offering SIP service are likely to fit that
scenario. However, since one content provider's network (single service pop
at least) will entirely be served by an ISP, it doesn't change much in terms
of problem definition. I think this merely creates sub-networks within
larger networks and borders within borders. The ISP may not have an SBC but
the Content provider may. My conclusion is that the domain of the SBC
related features and problems will not change in your picture (if I see it
right ;).

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 3:11 PM
To: Brian Rosen; [email-masked]; Medhavi Bhatia; Richard Fogel;
[email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Brian,

I am trying to gain some clarity in definitions.  Terms get thrown around
rather loosely.  Perimeter or edge for one protocol or layer may be entirely
somewhere else for another protocol or layer.  Yet some of this discussion
seems to assume that they are geographically or perhaps topologically found
in the same box or adjacent boxes.  I'm not so sure.  Such assumptions may
not apply in all cases, and it may not be good to design in such
constraints.  Assumptions about IP addresses may not hold.  Signaling and
media may need to take different routes.  I don't have a clear picture yet
in my head, but I wouldn't want to get boxed into one way of doing things.

Mike

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Thursday, February 24, 2005 2:19 PM
To: Michael Hammer (mhammer); [email-masked]; 'Medhavi Bhatia';
'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I don't think I agree.

A carrier (ITSP) deploys an SBC to protect his network from his customers
and his peers.

An enterprise/residence/. deploys an SBC to protect his internal domain from
any caller from any external domain.

We observe that there are more similarities than differences, but there are
differences.

It is pretty unusual for an enterprise/residential network to deploy an SBC
anywhere other than the perimeter of their network.

It is pretty unusual for a carrier to deploy an SBC anywhere other than the
perimeter of the "service" (voice/video/text/.) part of their network.

In both cases, you may have some packet level boxes between the SBC and the
actual edge of the network, but logically, they are both the last box facing
the rest of the world.

Brian

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 1:53 PM
To: [email-masked]; Brian Rosen; Medhavi Bhatia; Richard Fogel;
[email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Henry,

One of the issues is what we mean by network or perimeter.  From the
perspective of the network transport mechanisms, a SIP sending device may be
centered in the data network somewhere multiple router hops away from the
data network edge.  But, from the perspective of the SIP application layer,
the SIP sending device may be the last such device to operate on SIP (think
TLS connection) within that network before egressing that data network to
another data network.  Put another way, it is perimeter for the ITSP, but
not perimeter for the ISP, both of which might be the same SP.  The
co-location topologically of SBC with NAT or FW begs for a picture to be
drawn.  Else, we are blind men describing an (white?) elephant.

Another aspect is, from the SIP application layer perspective, one type of
ITSP SIP perimeter device is used to peer with another ITSP SIP perimeter
device.  Another type of perimeter device interfaces with a customer SIP
perimeter device (e.g. IP-PBX) or simply a customer IAD or SIP IP Phone.
Client side v. Network side sort of captures this facet, but I am leery of
the term client that slides too easily into UAC v. UAS, v. Proxy
connotations.  Hard to differentiate, when there is a peer-to-peer aspect to
this.  Because of mobility, perhaps there really is no distinction between
customer and ITSP peer interfaces.

The SBC concept seems to infer that there is an "inside" versus "outside".
With mobility the devices supposedly on the "inside" may really be on the
"outside" from the data network perspective.  Ultimately, it seems a given
SIP message is addressed to a particular SIP peer and pops up out of the
data network at that peer's IP/port doorstep.  If the SIP device does not
have any relationship to the message sender, it can forward/redirect on to
another device or ignore that request.  It would seem this devolves into SIP
devices ensuring that the proper sequence of SIP devices is traversed so
that SIP functions are performed in the proper order.  Leading back to what
SIP border functions are needed.  These may depend on whether the
relationships are native or non-native.

Mike

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 24, 2005 12:14 PM
To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

>How about client side and network side?

1. The intermediaries used in carrier networks (often referred to as SBC in
a confusing manner) could be called "Network based Session Controllers" or
NSC.

2. The intermediaries at the perifery of private IP networks, colocated with
the NAT/FW could be called "Perimeter Session Controllers" or PSC.

Thanks, Henry

  _____  

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 10:43 AM
To: [email-masked]; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Henry

As always, you wield a sharp sword.  I think you are correct, we need to
differentiate a client side SBC from a network side SBC and we need names.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 24, 2005 10:45 AM
To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Medhavi,

It appears the location of such intermediaries makes the critical
difference:

1. SBC placed in the network (in the C.O.) of the carrier, or 

2. A perimeter device (such as Borderware or SIP media Proxy - these are
product names ) that is collocated as CPE with the NAT and Firewall. This
co-location changes many security aspects (we need to specify which) and
also the media performance, as well as bandwidth consumption. Multi-homing
is an issue here, not to forget.

I suggest we should always make this distinction. Maybe someone proposes
some definitions or names for each.

Thanks, Henry