That's right. Redo logs are never backed up explicitly, which is why you don't see any option to do so. That doesn't mean that they don't get backed up at all. To see what is happening "behind the scenes", please take a look at selected output of one of my backup jobs, which does a level 0 database backup followed by an archive log backup.
After connecting to the database and recovery catalog, the first thing that happens is the level 0 backup. According to the job log, the command being executed is
rman job log said:
RMAN> backup incremental level 0 cumulative device type disk tag 'LEVEL0_BACKUP_OP03_070409090024' database;
There follows various log messages about allocating i/o channels and which database files are included in which backup sets. Eventually the database backup finishes with the message
rman job log said:
channel ORA_DISK_2: backup set complete, elapsed time: 01:31:47
Finished backup at 04-JUL-09
Rman then does an autobackup of the control file and spfile, after which it is ready to start the archive log backup. The command for this is
rman job log said:
RMAN> backup device type disk tag 'LEVEL0_BACKUP_OP03_070409090024' archivelog all not backed up delete all input;
At this point rman has to deal with the fact that there is a partially full redo log that is in danger of not getting backed up. Rman is smart enough to know that this needs to be done as part of its "backup...archivelog all" command, even though you haven't explicitly asked for it to be done. So, the very first thing in the job log after the backup archivelog command is
rman job log said:
Starting backup at 04-JUL-09
current log archived
Rman has just forced a log switch, so the contents of the redo log is written to archive, ready and waiting to be backed up along with all the other archive log files.
So you can stop looking for an option in Database Control to back up the redo log. Oracle already knows what has to be done and includes it as part of its normal backup procedures.