Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)
draft-ietf-ips-fcip-slp-09
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3822.
|
|
---|---|---|---|
Author | David Peterson | ||
Last updated | 2020-01-21 (Latest revision 2004-02-04) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 3822 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Allison J. Mankin | ||
Send notices to | <ElizabethRodriguez@ieee.org> |
draft-ietf-ips-fcip-slp-09
IPS Working Group David Peterson INTERNET-DRAFT SBS Technologies <draft-ietf-ips-fcip-slp-09.txt> January 2004 Expires: July 2004 Category: standards-track Finding FCIP Entities Using SLPv2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the use of Service Location Protocol version 2 (SLPv2), by Fibre Channel over TCP/IP (FCIP) Entities. 1. Introduction This document describes the use of Service Location Protocol version 2 to perform dynamic discovery of participating Fibre Channel over TCP/IP (FCIP) Entities. Implementation guidelines, service type templates, and security considerations are specified. Peterson Standards Track [Page 1] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 2. Notation Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDEDNandakumar & Jennings Expires January 8, 2017 [Page 82] Internet-Draft SDP4WebRTC July 2016 | c=IN IP4 98.248.92.77 | [RFC4566] | | a=rtcp:49203 IN IP4 98.248.92.77 | [RFC3605] | | a=mid:m0 | [RFC5888] Audio m=line part | | | of BUNDLE group with a unique | | | port number | | a=msid:ma ta | Identifies RTCMediaStream ID | | | (ma) and RTCMediaStreamTrack | | | ID (ta) | | a=recvonly | [RFC3264] | | a=rtpmap:109 opus/48000/2 | [I-D.ietf-payload-rtp-opus] | | a=maxptime:120 | [RFC4566] | | a=ice-ufrag:074c6550 | [RFC5245] | | a=ice-pwd:a28a397a4c3f31747d1ee34 | [RFC5245] | | 74af08a068 | | | a=fingerprint:sha-256 6B:8B:F0:65 | [RFC5245] | | :5F:78:E2:51:3B:AC:6F:F3:3F:46:1B | | | :35 :DC:B8:5F:64:1A:24:C2:43:F0:A | | | 1:58:D0:A1:2C:19:08 | | | a=setup:active | [RFC4145] | | a=rtcp-mux | [RFC5761] | | a=rtcp-rsize | [RFC5506] | | a=rtcp-fb:109 nack | [RFC5104] | | a=extmap:1 urn:ietf:params:rtp- | [RFC6464] | | hdrext:ssrc-audio-level | | | a=extmap:2 urn:ietf:params:rtp- | [I-D.ietf-mmusic-sdp-bundle-n | | hdrext:sdes:mid | egotiation] | | a=ssrc:54321 | [RFC5576] | | cname:Q/NWs1ao1HmN4Xa5 | | | a=candidate:0 1 UDP 2113667326 | [RFC5245] | | 192.168.1.7 51556 typ host | | | a=candidate:1 1 UDP 1694302206 | [RFC5245] | | 98.248.92.77 49203 typ srflx | | | raddr 192.168.1.7 rport 51556 | | | a=end-of-candidates | [I-D.ietf-mmusic-trickle-ice] | | ****** Video m=line ********* | ***************************** | | m=video 49203 UDP/TLS/RTP/SAVPF | BUNDLE accepted with Bundle | | 98 100 101 103 | Address identical to audio | | | m=line. | | c=IN IP4 98.248.92.77 | [RFC4566] | | a=rtcp:49203 IN IP4 98.248.92.77 | [RFC3605] | | a=mid:m1 | [RFC5888] Video m=line part | | | of BUNDLE group | | a=msid:ma tb | Identifies RTCMediaStream ID | | | (ma) and RTCMediaStreamTrack | | | ID (tb) | | a=recvonly | [RFC3264] | | a=rtpmap:98 VP8/90000 | [I-D.ietf-payload-vp8] | | a=rtpmap:100 VP8/90000 | [I-D.ietf-payload-vp8] | Nandakumar & Jennings Expires January 8, 2017 [Page 83] Internet-Draft SDP4WebRTC July 2016 | a=rtpmap:101 flexfec/90000 | [I-D.ietf-payload-flexible-fe | | | c-scheme] | | a=rtpmap:103 flexfec/90000 | [I-D.ietf-payload-flexible-fe | | | c-scheme] | | a=fmtp:98 max-fr=30;max-fs=8040 | [RFC4566] | | a=fmtp:100 max-fr=15;max-fs=1200 | [RFC4566] | | a=fmtp:101 L=5; D=10; ToP=2; | [I-D.ietf-payload-flexible-fe | | repair-window=200000 | c-scheme] | | a=fmtp:103 L=5; D=10; ToP=2; | [I-D.ietf-payload-flexible-fe | | repair-window=200000 | c-scheme] | | a=fingerprint:sha-256 6B:8B:F0:65 | [RFC5245] | | :5F:78:E2:51:3B:AC:6F:F3:3F:46:1B | | | :35 :DC:B8:5F:64:1A:24:C2:43:F0:A | | | 1:58:D0:A1:2C:19:08 | | | a=setup:active | [RFC4145] | | a=rtcp-mux | [RFC5761] | | a=rtcp-rsize | [RFC5506] | | a=rtcp-fb:* nack | [RFC5104] | | a=rtcp-fb:* nack pli | [RFC5104] | | a=rtcp-fb:* ccm fir | [RFC5104] | | a=extmap:2 urn:ietf:params:rtp- | [I-D.ietf-mmusic-sdp-bundle-n | | hdrext:sdes:mid | egotiation] | | a=ssrc:98765 | [RFC5576] | | cname:EocUG1f0fcg/yvY7 | | | a=rid:1 recv pt=98; | [I-D.ietf-mmusic-rid] | | a=rid:2 recv pt=100; | [I-D.ietf-mmusic-rid] | | a=simulcast: recv 1;2 | [I-D.ietf-mmusic-sdp-simulcas | | | t] | +-----------------------------------+-------------------------------+ Table 34: 5.3.5 SDP Answer 5.4. Others The examples in the section provide SDP Offer/Answer exchange for a variety of scenarios related to RTP Header extension for conference usages, Legacy Interop scenarios and more. 5.4.1. Audio Session - Voice Activity Detection This example shows Alice indicating the support of the RTP header extension to include the audio-level of the audio sample carried in the RTP packet. Nandakumar & Jennings Expires January 8, 2017 [Page 84] Internet-Draft SDP4WebRTC July 2016 2-Way Audio with VAD Alice Bob | | | | |Alice indicates support for including | |audio level in RTP header | | | | Offer(Audio:Opus,PCMU,PCMA) | |---------------------------------------->| | | | | | Answer(Audio:Opus,PCMU,PCMA) | |<----------------------------------------| | | | |Bob accepts and | |indicates his | |support as well | | | Two way Opus Audio | |.........................................| | | |Per packet audio-level is included in the| |RTP header | | | +-----------------------------------+-------------------------------+ | Offer SDP Contents | RFC#/Notes | +-----------------------------------+-------------------------------+ | v=0 | [RFC4566] | | o=- 20518 0 IN IP4 0.0.0.0 | [RFC4566] | | s=- | [RFC4566] | | t=0 0 | [RFC4566] | | a=group:BUNDLE audio | [I-D.ietf-mmusic-sdp-bundle-n | | | egotiation] | | a=ice-options:trickle | [I-D.ietf-mmusic-trickle-ice] | | ****** Audio m=line ********* | ***************************** | | m=audio 54609 UDP/TLS/RTP/SAVPF | [RFC4566] | | 109 0 8 | | | c=IN IP4 24.23.204.141 | [RFC4566] | | a=rtcp:54609 IN IP4 24.23.204.141 | [RFC3605] | | a=mid:audio | [RFC5888] | | a=msid:ma ta | Identifies RTCMediaStream ID | | | (ma) and RTCMediaStreamTrack | | | ID (ta) | | a=sendrecv | [RFC3264] | Nandakumar & Jennings Expires January 8, 2017 [Page 85] Internet-Draft SDP4WebRTC July 2016 | a=rtpmap:109 opus/48000/2 | [I-D.ietf-payload-rtp-opus] | | a=rtpmap:0 PCMU/8000 | [RFC3551] | | a=rtpmap:8 PCMA/8000 | [RFC3551] | | a=maxptime:120 | [RFC4566] | | a=ice-ufrag:074c6550 | [RFC5245] | | a=ice-pwd:a28a397a4c3f31747d1ee34 | [RFC5245] | | 74af08a068 | | | a=fingerprint:sha-256 19:E2:1C:3B | [RFC5245] | | :4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73 | | | :04 :BB:05:2F:70:9F:04:A9:0E:05:E | | | 9:26:33:E8:70:88:A2 | | | a=setup:actpass | [RFC4145] | | a=rtcp-mux | [RFC5761] | | a=rtcp-rsize | [RFC5506] | | a=rtcp-fb:* nack | [RFC5104] | | a=extmap:1 urn:ietf:params:rtp- | [RFC6464] | | hdrext:ssrc-audio-level | | | a=extmap:2 urn:ietf:params:rtp- | [I-D.ietf-mmusic-sdp-bundle-n | | hdrext:sdes:mid | egotiation] | | a=ssrc:12345 | [RFC5576] | | cname:EocUG1f0fcg/yvY7 | | | a=candidate:0 1 UDP 2113667327 | [RFC5245] | | 192.168.1.4 61665 typ host | | | a=candidate:1 1 UDP 694302207 | [RFC5245] | | 24.23.204.141 54609 typ srflx | | | raddr 192.168.1.4 rport 61665 | | | a=end-of-candidates | [I-D.ietf-mmusic-trickle-ice] | +-----------------------------------+-------------------------------+ Table 35: 5.4.1 SDP Offer +-----------------------------------+-------------------------------+ | Answer SDP Contents | RFC#/Notes | +-----------------------------------+-------------------------------+ | v=0 | [RFC4566] | | o=- 16833 0 IN IP4 0.0.0.0 | [RFC4566] | | s=- | [RFC4566] | | t=0 0 | [RFC4566] | | a=group:BUNDLE audio | [I-D.ietf-mmusic-sdp-bundle-n | | | egotiation] | | a=ice-options:trickle | [I-D.ietf-mmusic-trickle-ice] | | ****** Audio m=line ********* | ***************************** | | m=audio 49203 UDP/TLS/RTP/SAVPF | [RFC4566] | | 109 0 98 | | | c=IN IP4 98.248.92.77 | [RFC4566] | | a=rtcp:49203 IN IP4 98.248.92.77 | [RFC3605] | | a=mid:audio | [RFC5888] | Nandakumar & Jennings Expires January 8, 2017 [Page 86] quot;, "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology Here are some definitions that may aid readers that are unfamiliar with either SLP, or FCIP. Some of these definitions have been reproduced from [RFC2608] and [RFC3105]. User Agent (UA) A process working on the client's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents. Service Agent (SA) A process working on behalf of one or more services to advertise the services and their capabilites. Directory Agent (DA) A process which collects service advertisements. There can only be one DA present per given host. Scope A named set of services, typically making up a logical administrative group. Service Advertisement A URL, attributes, and a lifetime (indicating how long the advertisement is valid), providing service access information and capabilities description for a particular service. FCIP Entity The principle FCIP interface point to the IP network. FCIP Entity Name The world wide name of the switch if the FCIP Entity resides in a switch or the world wide node name of the associated Nx_Port. FCIP Discovery Domain The FCIP Discovery Domain specifies which FCIP Entities are allowed to discover each other within the bounds of the scope. Peterson Standards Track [Page 2] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 4. Using SLPv2 for FCIP Service Discovery At least two FCIP Entities must be involved in the entity discovery process. The end result is that an FCIP Entity will discover one or more peer FCIP Entities. 4.1. Discovering FCIP Entities using SLPv2 The following diagram shows the relationship between FCIP Entities and their associated SLPv2 agents. +--------------------------------------+ | FCIP Entity | +----------------------------------+ | | FCIP Control and Services Module | | +----------------+ | | | SA | UA | | | +----------------+-----------------+ | | TCP/UDP/IP | | +----------------+-----------------+ | | Interface | | | 192.0.2.10 | | +----------------+-----------------+---| | +------------+ | | SLPv2 DA |----+ IP Network +------------+ | | +----------------+-----------------+---| | Interface | | | 192.0.2.20 | | +----------------+-----------------+ | | TCP/UDP/IP | | +----------------+-----------------+ | | SA | UA | | | +----------------+ | | | FCIP Control and Services Module | | +--------------------------------- + | | FCIP Entity | +--------------------------------------+ Fig. 1 FCIP Entity and SLPv2 Agent Relationship. As indicated in the drawing above, each FCIP Entity contains an FCIP Control and Services Module that interfaces to an SLPv2 SA and UA. The SA constructs a service advertisement of the type Peterson Standards Track [Page 3] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 "service:fcip:entity" for each of the service URLs it wishes to register. The service advertisement contains a lifetime, along with other attributes defined in the service template. The remainder of the discovery process is identical to that used by any client/server pair implementing SLPv2: 1. If an SLPv2 DA is found [RFC2608], the SA contacts the DA and registers the service advertisement. Whether or not one or more SLPv2 DAs are discovered, the SA maintains the service advertisement itself and answers multicast UA queries directly. 2. When the FCIP Entity requires contact information for a peer FCIP Entity, the UA either contacts the DA using unicast or the SA using multicast using an SLPv2 service request. The UA service request includes a query, based on the attributes, to indicate the characteristics of the peer FCIP Entities it requires. 3. Once the UA has the IP address and port number of a peer FCIP Entity, it may begin the normal connection procedure, as described in [FCIP], to a peer FCIP Entity. The use of a DA is RECOMMENDED for SLPv2 operation in an FCIP environment. 4.1.1. FCIP Discovery Domains The concept of a discovery domain provides further granularity of control of allowed discovery between FCIP Entities within a specific SLPv2 scope. The following example diagram shows the relationship between FCIP Entities and their associated discovery domains within a specified SLPv2 scope. Peterson Standards Track [Page 4] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 =================fcip======================================= = = = *************************purple*********************** = = * * = = * #####orange###################### * = = * # ------------ //////blue//////+/////////////// * = = * # | FCIP | / # / * = = * # | Entity A | / # / * = = * # ------------ / # ------------ / * = = * # / # | FCIP | / * = = * # / # | Entity C | / * = = * # / ------------ # ------------ / * = = * # / | FCIP | # / * = = * # / | Entity B | # / * = = * # / ------------ # / * = = * ################+################ / * = = * //////////////////////////////// * = = * * = = ****************************************************** = = = ============================================================ Fig. 2 FCIP Entity and Discovery Domain Example. Within the specified scope "fcip", the administrator has defined a discovery domain "purple", allowing FCIP Entities A, B, and C to discover each other. This discovery domain is illustrated using the "*" character. Within the specified scope "fcip", the administrator has defined a discovery domain "orange", allowing FCIP Entity A to discover FCIP Entity B, but not FCIP Entity C. This discovery domain is illustrated using the "#" character. Within the specified scope "fcip", the administrator has defined a discovery domain "blue", allowing FCIP Entity C to discover FCIP Entity B, but not FCIP Entity A. This discovery domain is illustrated using the "/" character. For this example, the value of the fcip-discovery-domain attribute for each FCIP Entity is as follows: FCIP Entity A = orange,purple FCIP Entity B = orange,blue,purple FCIP Entity C = blue,purple Peterson Standards Track [Page 5] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 4.2. NAT and NAPT Considerations Since SLPv2 provides IP address and TCP port information within its payload, the addresses an SA or DA advertise may not be the same as those a UA must use if a Network Address(/Port) Translation (NAT/NAPT) device is present between the UA and the SA. This may result in the UA discovering address information that is unusable. Also note that SLP advertisements that occur inside a private address realm may be unreachable outside that realm. Below are some recommendations for dealing with SLPv2 and NAT/NAPT devices: - A fully-qualified domain name (i.e., not an IP address) SHOULD be used in service URLs and the mgmt-entity attribute [RFC1900]. - Configure the NAPT device to provide default mapping(s) for the well-known port(s) and use the default IANA-assigned FCIP TCP port number in service URLs, when possible. 5. FCIP SLPv2 Templates Two templates are provided: an FCIP Entity template, and an abstract template to provide a means to add other FCIP related templates in the future. 5.1. The FCIP Abstract Service Type Template This template defines the abstract service "service:fcip". It is used as a top-level service to encapsulate all other FCIP related services. Name of submitter: David Peterson Language of service template: en Security Considerations: see section 6. Template Text: -------------------------template begins here----------------------- template-type=fcip template-version=0.1 template-description= This is an abstract service type. The purpose of the fcip service type is to encompass all of the services used to support the FCIP protocol. template-url-syntax = Peterson Standards Track [Page 6] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 url-path= ; Depends on the concrete service type. --------------------------template ends here------------------------ 5.2. The FCIP Entity Concrete Service Type Template This template defines the service "service:fcip:entity". A device containing FCIP Entities that wishes to have them discovered via SLPv2 would register each of them, with each of their addresses, as this service type. FCIP Entities wishing to discover other FCIP Entities in this manner will generally use one of the following example query strings: 1. Find a specific FCIP Entity, given its FCIP Entity Name: Service: service:fcip:entity Scope: fcip-entity-scope-list Query: (fcip-entity-name=\ff\10\00\00\60\69\20\34\0C) 2. Find all of the FCIP Entities within a specified FCIP Discovery Domain: Service: service:fcip:entity Scope: fcip-entity-scope-list Query: (fcip-discovery-domain=fcip-discovery-domain-name) 3. In addition, a management application may wish to discover all FCIP Entities: Service: service:fcip:entity Scope: management-service-scope-list Query: none Name of submitter: David Peterson Language of service template: en Security Considerations: see section 6. Template Text: -------------------------template begins here----------------------- template-type=fcip:entity template-version=0.1 template-description= This is a concrete service type. The fcip:entity service type is used to register individual FCIP Entity addresses to be discovered Peterson Standards Track [Page 7] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 by others. UAs will generally search for these by including one of the following: - the FCIP Entity Name for which an address is needed - the FCIP Discovery Domain Name for which addresses are requested - the service URL template-url-syntax = url-path = hostport hostport = host [ ":" port ] host = hostname / hostnumber hostname = *( domainlabel "." ) toplabel alphanum = ALPHA / DIGIT domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum toplabel = ALPHA / ALPHA * [ alphanum / "-" ] alphanum hostnumber = ipv4-number ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) port = 1*DIGIT ; ; A DNS host name should be used along with the well-known ; IANA FCIP port number for operation with NAT/NAPT devices. ; ; Examples: ; service:fcip:entity://host.example.com ; service:fcip:entity://192.0.2.0:4000 ; fcip-entity-name = opaque L # If the FCIP Entity is a VE_Port/B_Access implementation [FC-BB-2] # residing in a switch, the fcip-entity-name is the Fibre Channel # Switch Name [FC-SW-2]. Otherwise, the fcip-entity-name is the # Fibre Channel Node Name [FC-FS] of the port (e.g., an Nx_Port) # associated with the FCIP Entity. # An entity representing multiple endpoints must register each of # the endpoints using SLPv2. transports = string M L tcp # This is a list of transport protocols that the registered entity # supports. FCIP is currently supported over TCP only. tcp mgmt-entity = string M O L # The URL's of the management interface(s) appropriate for SNMP, # web-based, or telnet management of the FCIP Entity. # Examples: # snmp://192.0.2.0 # http://fcipentity.example.com:1080/ Peterson Standards Track [Page 8] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 # telnet://fcipentity.example.com fcip-discovery-domain = string M L fcip # The fcip-discovery-domain string contains the name(s) of the FCIP # discovery domain(s) to which this FCIP Entity belongs. --------------------------template ends here------------------------ 6. Security Considerations The SLPv2 security model as specified in [RFC2608] does not provide confidentiality, but does provide an authentication mechanism for UAs to assure that service advertisements only come from trusted SAs with the exception that it does not provide a mechanism to authenticate "zero-result responses". See [IPS-SEC] for a discussion of the SLPv2 [RFC2608] security model. Once an FCIP Entity is discovered, authentication and authorization are handled by the FCIP protocol. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service does not comprimise their security. When no security is used for SLPv2, there is a risk of distribution of false discovery information. The primary countermeasure for this risk is authentication. When this risk is a significant concern, IPsec SAs SHOULD be used for FCIP traffic subject to this risk to ensure that FCIP traffic only flows between endpoints that have participated in IKE authentication. For example, if an attacker distributes discovery information falsely claiming that it is an FCIP endpoint, it will lack the secret information necessary to successfully complete IKE authentication, and hence will be prevented from falsely sending or receiving FCIP traffic. There remains a risk of a denial of service attack based on repeated use of false discovery information that will cause initiation of IKE negotiation. The countermeasures for this are administrative configuration of each FCIP Entity to limit the peers that it is willing to communicate with (i.e., by IP address range and/or DNS domain), and maintenance of a negative authentication cache to avoid repeatedly contacting an FCIP Entity that fails to authenticate. These three measures (i.e., IP address range limits, DNS domain limits, negative authentication cache) MUST be implemented. Peterson Standards Track [Page 9] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 6.1. Security Implementation Security for SLPv2 in an IP storage environment is specified in [IPS- SEC]. IPsec SHOULD be implemented for SLPv2 as specified in [IPS-SEC]. This includes ESP with a non-null transform to provide both authentication and confidentiality. SLPv2 authentication is OPTIONAL to implement and use, and SLPv2 authentication SHOULD be implemented when IPsec is not supported. 7. IANA Considerations After RFC publication, an SLP designated expert will oversee registration of the template(s) in the IANA repository. 8. Internationalization Considerations SLP allows internationalized strings to be registered and retrieved. Attributes in the template that are not marked with an 'L' (literal) will be registered in a localized manner. An "en&Internet-Draft SDP4WebRTC July 2016& | a=msid:ma ta | Identifies RTCMediaStream ID | | | (ma) and RTCMediaStreamTrack | | | ID (ta) | | a=sendrecv | [RFC3264] - Bob can send and | | | recv audio | | a=rtpmap:109 opus/48000/2 | [I-D.ietf-payload-rtp-opus] - | | | Bob accepts only Opus Codec | | a=rtpmap:0 PCMU/8000 | [RFC3551] PCMU Audio Codec | | a=rtpmap:0 PCMA/8000 | [RFC3551] PCMA Audio Codec | | a=maxptime:120 | [RFC4566] | | a=ice-ufrag:c300d85b | [RFC5245] | | a=ice-pwd:de4e99bd291c325921d5d47 | [RFC5245] | | efbabd9a2 | | | a=fingerprint:sha-256 6B:8B:F0:65 | [RFC5245] | | :5F:78:E2:51:3B:AC:6F:F3:3F:46:1B | | | :35 :DC:B8:5F:64:1A:24:C2:43:F0:A | | | 1:58:D0:A1:2C:19:08 | | | a=setup:active | [RFC4145] | | a=rtcp-mux | [RFC5761] - Bob can perform | | | RTP/RTCP Muxing on port 49203 | | a=rtcp-rsize | [RFC5506] | | a=rtcp-fb:* nack | [RFC5104] | | a=extmap:1 urn:ietf:params:rtp- | [RFC6464] | | hdrext:ssrc-audio-level | | | a=extmap:2 urn:ietf:params:rtp- | [I-D.ietf-mmusic-sdp-bundle-n | | hdrext:sdes:mid | egotiation] | | a=ssrc:54321 | [RFC5576] | | cname:Q/NWs1ao1HmN4Xa5 | | | a=candidate:0 1 UDP 2113667327 | [RFC5245] | | 192.168.1.7 51556 typ host | | | a=candidate:1 1 UDP 1694302207 | [RFC5245] | | 98.248.92.77 49203 typ srflx | | | raddr 192.168.1.7 rport 51556 | | | a=end-of-candidates | [I-D.ietf-mmusic-trickle-ice] | +-----------------------------------+-------------------------------+ Table 36: 5.4.1 SDP Answer 5.4.2. Audio Conference - Voice Activity Detection This example shows SDP for RTP header extension that allows RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Nandakumar & Jennings Expires January 8, 2017 [Page 87] Internet-Draft SDP4WebRTC July 2016 Audio Conference with VAD Support Alice Mixer | | |Alice indicates her interest to audio | |levels for the contributing sources | | | |Offer(Audio:Opus,PCMU,PCMA) | |---------------------------------------->| | | | | |Answer(Audio:Opus,PCMU,PCMA) | |<----------------------------------------| | | | |Mixer indicates | |it can provide | |audio-levels |Two way Opus Audio | |.........................................| | | |Audio-levels per CSRCS is included in the| |RTP header | | | +-----------------------------------+-------------------------------+ | Offer SDP Contents | RFC#/Notes | +-----------------------------------+-------------------------------+ | v=0 | [RFC4566] | | o=- 20518 0 IN IP4 0.0.0.0 | [RFC4566] - Session Origin | | | Information | | s=- | [RFC4566] | | t=0 0 | [RFC4566] | | a=group:BUNDLE audio | [I-D.ietf-mmusic-sdp-bundle-n | | | egotiation] | | a=ice-options:trickle | [I-D.ietf-mmusic-trickle-ice] | | ****** Audio m=line ********* | ***************************** | | m=audio 54609 UDP/TLS/RTP/SAVPF | [RFC4566] | | 109 0 8 | | | c=IN IP4 24.23.204.141 | [RFC4566] | | a=rtcp:54609 IN IP4 24.23.204.141 | [RFC3605] | | a=mid:audio | [RFC5888] | | a=msid:ma ta | Identifies RTCMediaStream ID | | | (ma) and RTCMediaStreamTrack | | | ID (ta) | | a=sendrecv | [RFC3264] - Alice can send | | | and recv audio | Nandakumar & Jennings Expires January 8, 2017 [Page 88] Internet-Draft SDP4WebRTC July 2016 | a=rtpmap:109 opus/48000/2 | [I-D.ietf-payload-rtp-opus] | | a=rtpmap:0 PCMU/8000 | [RFC3551] PCMU Audio Codec | | a=rtpmap:0 PCMA/8000 | [RFC3551] PCMA Audio Codec | | a=maxptime:120 | [RFC4566] | | a=ice-ufrag:074c6550 | [RFC5245] | | a=ice-pwd:a28a397a4c3f31747d1ee34 | [RFC5245] | | 74af08a068 | | | a=fingerprint:sha-256 19:E2:1C:3B | [RFC5245] | | :4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73 | | | :04 :BB:05:2F:70:9F:04:A9:0E:05:E | | | 9:26:33:E8:70:88:A2 | | | a=setup:actpass | [RFC4145] | | a=rtcp-mux | [RFC5761] | | a=rtcp-rsize | [RFC5506] | | a=rtcp-fb:* nack | [RFC5104] | | a=extmap:1/recvonly | [RFC6465] | | urn:ietf:params:rtp-hdrext:csrc- | | | audio-level | | | a=extmap:2 urn:ietf:params:rtp- | [RFC6464] | | hdrext:ssrc-audio-level | | | a=extmap:3 urn:ietf:params:rtp- | [I-D.ietf-mmusic-sdp-bundle-n | | hdrext:sdes:mid | egotiation] | | a=ssrc:12345 | [RFC5576] | | cname:EocUG1f0fcg/yvY7 | | | a=candidate:0 1 UDP 2113667327 | [RFC5245] | | 192.168.1.4 61665 typ host | | | a=candidate:1 1 UDP 694302207 | [RFC5245] | | 24.23.204.141 54609 typ srflx | | | raddr 192.168.1.4 rport 61665 | | | a=end-of-candidates | [I-D.ietf-mmusic-trickle-ice] | +-----------------------------------+-------------------------------+ Table 37: 5.4.2 SDP Offer +-----------------------------------+-------------------------------+ | Answer SDP Contents | RFC#/Notes | +-----------------------------------+-------------------------------+ | v=0 | [RFC4566] | | o=- 16833 0 IN IP4 0.0.0.0 | [RFC4566] - Session Origin | | | Information | | s=- | [RFC4566] | | t=0 0 | [RFC4566] | | a=group:BUNDLE audio | [I-D.ietf-mmusic-sdp-bundle-n | | | egotiation] | | a=ice-options:trickle | [I-D.ietf-mmusic-trickle-ice] | | ****** Audio m=line ********* | ***************************** | | m=audio 49203 UDP/TLS/RTP/SAVPF | [RFC4566] | Nandakumar & Jennings Expires January 8, 2017 [Page 89] Internet-Draft SDP4WebRTC July 2016 | 109 0 98 | | | c=IN IP4 98.248.92.77 | [RFC4566] | | a=rtcp:49203 IN IP4 98.248.92.77 | [RFC3605] | | a=mid:audio | [RFC5888] | | a=msid:ma ta | Identifies RTCMediaStream ID | | | (ma) and RTCMediaStreamTrack | | | ID (ta) | | a=sendrecv | [RFC3264] | | a=rtpmap:109 opus/48000/2 | [I-D.ietf-payload-rtp-opus] | | a=rtpmap:0 PCMU/8000 | [RFC3551] PCMU Audio Codec | | a=rtpmap:0 PCMA/8000 | [RFC3551] PCMA Audio Codec | | a=maxptime:120 | [RFC4566] | | a=ice-ufrag:c300d85b | [RFC5245] | | a=ice-pwd:de4e99bd291c325921d5d47 | [RFC5245] | | efbabd9a2 | | | a=fingerprint:sha-256 6B:8B:F0:65 | [RFC5245] | | :5F:78:E2:51:3B:AC:6F:F3:3F:46:1B | | | :35 :DC:B8:5F:64:1A:24:C2:43:F0:A | | | 1:58:D0:A1:2C:19:08 | | | a=setup:active | [RFC4145] | | a=rtcp-mux | [RFC5761] | | a=rtcp-rsize | [RFC5506] | | a=rtcp-fb:* nack | [RFC5104] | | a=extmap:1/sendonly | [RFC6465] | | urn:ietf:params:rtp-hdrext:csrc- | | | audio-level | | | a=extmap:2 urn:ietf:params:rtp- | [I-D.ietf-mmusic-sdp-bundle-n | | hdrext:sdes:mid | egotiation] | | a=ssrc:54321 | [RFC5576] | | cname:Q/NWs1ao1HmN4Xa5 | | | a=candidate:0 1 UDP 2113667327 | [RFC5245] | | 192.168.1.7 51556 typ host | | | a=candidate:1 1 UDP 1694302207 | [RFC5245] | | 98.248.92.77 49203 typ srflx | | | raddr 192.168.1.7 rport 51556 | | | a=end-of-candidates | [I-D.ietf-mmusic-trickle-ice] | +-----------------------------------+-------------------------------+ Table 38: 5.4.2 SDP Answer 5.4.3. Successful legacy Interop Fallback with bundle-only In the scenario described below, Alice is a multi-stream capable WebRTC endpoint while Bob is a legacy VOIP end-point. The SDP Offer/ Answer exchange demonstrates successful session setup with fallback to audio only stream negotiated via bundle-only framework between the end-points. Specifically, Nandakumar & Jennings Expires January 8, 2017 [Page 90] Internet-Draft SDP4WebRTC July 2016 o Offer from Alice describes 2 cameras via 2 video m=lines with both marked as bundle-only. o Since Bob doesnot recognize either the BUNDLE mechanism or the bundle-only attribute, he accepts only the audio stream from Alice. NOTE: Since Alice is unaware of Bob's support for BUNDLE framework, Alice ensures to include separate RTP/RTCP ports and candidate information. Successful 2-Way WebRTC <-> VOIP Interop Alice Bob | | | | | Alice is a multistream capable WebRTC end-point | | & Bob is behind a legacy VOIP system | | | |Offer(Audio:Opus Video:2 VP8,2 H2.64 Streams) with | | bundle-only | |---------------------------------------------------------->| | Alice marks both the video streams as bundle-only | | | | | | Answer(Audio:Opus) | |<----------------------------------------------------------| | |Bob | |accepts | |audio | |stream, | |since he | |doesn't | |recognize | |bundle-only | | | Two way Opus Audio | |...........................................................| | | | | +-------------------------------------+-----------------------------+ | Offer SDP Contents | RFC#/Notes | +-------------------------------------+-----------------------------+ | v=0 | [RFC4566] | | o=- 20519 0 IN IP4 0.0.0.0 | [RFC4566] | Nandakumar & Jennings Expires January 8, 2017 [Page 91] Internet-Draft SDP4WebRTC July 2016 quot; (English) localization MUST be registered, and others MAY be registered. 9. Summary This document describes how SLPv2 can be used by FCIP Entities to find other FCIP Entities. Service type templates for FCIP Entities are presented. 10. Acknowledgements This draft was produced by the FCIP discovery team, including Todd Sperry (Adaptec), Larry Lamars (SanValley), Robert Snively (Brocade), Ravi Natarajan (Lightsand), Anil Rijhsinghani (McData), and Venkat Rangan (Rhapsody Networks). Thanks also to Mark Bakke (Cisco) for initial help and consultation, and David Black, Erik Guttman, and James Kempf for assistance during expert review. 11. Normative References The references in this section were current at the time this specification was approved. This specification is intended to operate with newer versions of the referenced documents. Looking for newer references is recommended. Peterson Standards Track [Page 10] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, version 2", RFC 2608, July 1999. [RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC1900] B. Carpenter, Y. Rekhter. "Renumbering Needs Work", RFC 1900, February 1996. [FCIP] Rajagopal, et. al. "FCIP", draft-ietf-ips- fcovertcpip-12.txt, February 2003. [FC-SW-2] Fibre Channel Switch Fabric - 2, ANSI INCITS.355:2001, December 12, 2001. [FC-BB-2] Fibre Channel Backbone - 2, T11 Project 1238-D, Rev 6.0, February 4, 2003. [FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D, Rev 1.90, April 9, 2003. [IPS-SEC] B. Aboba, et. al. "Securing Block Storage Protocols over IP", draft-ietf-ips-security-19.txt, January 14, 2003. 12. Informative References The references in this section may further assist the reader. [RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and service: Schemes", RFC 2609, July 1999. [RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC 2614, June 1999. [2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft- kempf-srvloc-rfc2614bis-00.txt, February 2001. [RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for SLP", RFC 3082, March 2001. [RFC3105] Kempf, J., Montenegro, G. "Finding an RSIP Server with SLP", RFC 3105, October 2001. [FCIP-MIB] Rijhsinghani, et. al. "FCIP MIB", draft-ietf-ips-fcip- mib-05.txt, December 2003. Peterson Standards Track [Page 11] Internet-Draft Finding FCIP Entities Using SLPv2 January 2004 Author's Address: David Peterson SBS Technologies, Inc. 1284 Corporate Center Dr. St. Paul, MN USA 55121 Voice: +1 651-905-4755 E-Mail: dap@sbs.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Peterson Standards Track [Page 12]